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This is the third edition or the AF3 ioyicai architecture by the 
Poughkeepsie Advanced Systems Group. It is a refinement and 
extension ot the second edition and is presented as a basis for 
further work and as a vehicle for communication between the 
several groups working on APS. Although the design effort has 
concentrated on the conceptual level, it is being supported by 
concurrent implementation studies tnat are discussed in the APS 
System Architecture Manual. 
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GUIDE TO READING I HIS REPORT 
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Part 1 


INTRODUCTION 


Since AFS is developing a new approach to computer system design, 
some background information is necessary to place the concepts in 
perspective and to ease tne transition to novel lines of thought. 
Chapter 1.1 presents an overview of the new concepts, the 
relationship between AFS and otner developments by IBM and 
competitors, and the objectives and requirements that AFS is 
trying to meet. Chapter 1.2 discusses underlying assumptions 
that motivate and direct the design effort. Finally, chapter 1.3 
presents the notation and syntactic conventions used throughout 
the remaining parts of this manual. 


IBM COMFiDJSNTIAL 




Chapter 1.1 
EXECUTIVE SUMMAHX 


1.1.1 A On e-Page Sum ma tion 


AFS, Advanced Future System, is proposed as an alternative to 
compatible extension of 5ystem/B70. It is intended to meet FS 
Market Requirements by Advanced Systems Planning and Evaluation. 
Basic elements of AFS include seif-describing data, reference to 
data by symbolic names rather than addresses, dynamic attribute 
examination, automatic storage Hierarchy, network runction 
transparency, and a high-level machine language called SL, the 
System Language. Such a runctionai base will provide a 

significant gain in system usability. This document presents a 
new conceptual foundation, ana describes SL and tae associated 
system facilities. A companion document, the AFS System 

Architecture Manual, discusses implementation and presents 
additional detail. 

The conceptual foundation for AFS is a synthesis or advances in 
Computer Science. It is modeled formally using the Vienna 
definition methods. It provides a framework tor multiprocessing, 
data independence, data base structures, source/sink ana network 
communications, modular control system structure, uniform 
resource management, and migration from 3ystem/360/J70 including 
coexistence and dynamic interchange. 

The number of AFS constructs is minimized by exploiting each 
fully. For example, assignment is the universal means to put 
something somewhere, whether assigning a value to a number, 
sending information to a printer, or filing a new program under 
some name. Similarly, an ’’object" has the same formal structure 
whether it represents numeric data, a data structure, a virtual 
device, a program environment, a function activation, an access 
authorization, a communication port, or any other system entity. 

SL is a complete language, wnose functions include those 
necessary to represent programs written in contemporary high 
level languages, as well as ail system control facilities. SL 
statements are constructed with these functions just as 
arithmetic expressions are constructed with arithmetic operators. 
A customer may use COBOL, PL/1, FQSTfiAN, APL, or EPS as if each 
were the actual machine language. SL is extendible: new 

functions and data structures are readily accommodated. 
Furthermore, the AFS design is such that facilities beneath the 
external interface may be redefined with SL functions. 
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1.1.2 B ackgr ound 


The conceptual foundation results from a fresh examination of 
fundamental data and control structures in light of the past 
decade of progress in computer science. The approach differs 
from earlier ones in that provision is made from the outset for 
essential is ingredients such as multiprocessing, data 
independence, data base structures, coexistence of multiple 
architectures (such as Bystem/37 0), network communications, 
applications subsystems, ana unified system resource management. 

The 3L design also differs from earlier approaches in basic 
character: The conceptual framework provides a oasis for an 

architecture wnich can grow gracefully, rather than one which is 
tightly circumscribed. Extensions and modifications can be 
defined in SL itself in such a manner that system discipline and 
integrity pervades aii levels of redefinition; user programs are 
written as though the extensions were an integral part of the 
system. 

This type of design is called a Recursively Extensible 
Architecture. it offers users the anility to extend or 
specialize subsystems for their particular reguirameats, system 
architects the ability to develop tne architecture without 
impacting customer programming investments, and IBM product 
designers the opportunity to buiid hardware to support either 
general or specialized mactional extensions. 


1. 1.2.1 Historical foundation 


design of the data and control structures required for a 
complete, functioning system uas historically been tne task of 
programmers. In the process of building increasingly complex 
systems, a systematic bouy of programming knowledge has 
developed. Central to this body oi knowledge is an understanding 
of fundamental structures and algorithms which occur throughout 
ail programming practice. Work in programming languages over the 
past ten years has to a large extent consisted of developing 
notations with which one can conveniently employ various subsets 
of these basic elements. The BE approach has been to survey the 
fundamental structures, determine a minimal set of basic 
concepts, and design a total external interface based upon this 
set. 
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1.1.2.2 Related IBM Activities 


There are a number or current activities that reiate directly or 
indirectly to AFS. System A in Research is examining an external 
interface similar to SL: System A is designed to run on an NS 
symmetric multiprocessor system, and programs at the external 
interface level will either oa compiled, into System/i70 code or 
be interpreted in an intermediate language similar to SL. The 
Endicott Advanced System Group has worxed on a similarly 
motivated design effort during the past several years. Their 
work, through 1970 is summarized m a February 1, 1971, report 

entitled HLS-Prot otype P roiec t Re po rt . More recently, Endicott 
ASG representatives have worked noth with the SL designers and 
with Ray Larner, who has formulated a proposal ror a high level 
interface called ML (Machine Language) . Several individuals in 
the San Jose Research Center nave been actively participating in 
AFS areas. The Palo Aito Scientific Center has microcode! a 
Model 23, and now a Model l4o, to interpret APL code directly. 
They have also conducted related studies concerning the 
performance of microcoded APL machines vs. conventional 
instructions and compilers. Much of the worx on data base 
organization is pertinent, especially the PROP/bB prototype in 
Poughkeepsie. The New Yorx Programming Center is studying the 
significance of an AFS-uxe architecture for the principal 
programming languages, and tae broader classes of languages and 
language building tools wmch may become possible. Prototype 
PL/I work done in tlurslay, in conjunction with the functional 
memory program, has shown several opportunities for significant 
performance improvement. wor x to date on the FP5 project has 
considered similar concepts, ana it seems that some commonality 
with the eventual FPS direction is likely. 


1. 1.2.3 Competition 


Numerous university and industrial investigators are exploring 
AFS-like directions. Some are exploring these directions with 
the intent of developing more efncieut microcode for existing 
hardware. Examples can be found in papers emanating from 
universities. Some manufacturers are producing microcodabie 
hardware which lends itself to providing higher ievei interfaces. 
Examples are the ICI and Gemini machines. There is considerable 
discussion of APL-lixe machines; CDC claims that the STAR system 
directly performs APL-lixe runctions. McFarland's paper in the 
1970 FJCC describes TPL (The Programming Language), tor which 
direct hardware support is discussed. Iliffe's Basic Machine and 
Sice's "PL/I" machine are further examples of machines which 
offer direct support of higher ievei external interfaces. By far 
the most experienced competitor to date is Burroughs; The B50QG 


IBM CONFXbENTIAL 




10 


introduction 


in the early sixties and the more recent B5700, B670G, and B7700 
all support a higher level interlace directly. Their 
architecture readily otters support, such as virtual memories and 
multiprocessing, which poses serious difficulties for OS or DOS. 
Their design has permitted construction of an operating system in 
a higher level ianguage. Further ueveiopment in AFS directions 
should he anticipated from Burroughs. 


1.1.3 O bject ives and heguirements 


AFS is intended as an alternative to a compatioie extension of 
System/370 for the FS time frame. AFS must therefore meet 
official FS Market Requirements rather than generate new ones. 
In tne event that any or these requirements are not achievable, 
AFS nas the oojective to equal or exceed the best FS proposal 
with System/370 compatible hardware. 

SL is the machine ianguage of AFS and therefore inherits the 
above requirements and any otner AFS requirement that has a 
ianguage implication. At present, these requirements are stated 
rn a memo, "AFS Require meats ana Objectives" Jan. 19, 1971, to €. 
J. Conti and A. A. Maydali from R. B. Bennett ana w, D. Wilson, A 
oner summary of the requirements iron tne SL point of view is 
given below: 

SL must allow the user to interact with AFS in a high level 
language and suffer neither the isolation from the maculae caused 
by compilers today nor tne inefficient execution caused by 
interpreters. Tuis is to he accomplished in two ways: on the 
one hand, the machine language itself will be a high level 
language exploiting current language technology; on the other 
hand, tne user will be aoie to act as it the machine language 
were any one of five favored languages—COBOL, FORTRAN, PL/I, 
RPC, and APL--and he must not suffer a serious performance 
penalty for ignoring machine language. 

To meet this requirement, Sr must faithfully interpret the five 
favored languages: Under AFS, tne conversational user must be 

able to interrupt execution, maxe changes, resume execution, 
execute incomplete or defective code as long as it maxes sense to 
do so, and yet the lull benerits or a really good interpreter of 
the language without paying the performance penalty normally 
associated with interpretation. 

SL must be an appropriate ooject language for the interpreters 
mentioned above and for compilers from the current principal 
high-level languages, extensions tnat will be made to them, and 
new programming languages that may oecome popular in the FS time 
frame. 
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Security, privacy, and system integrity must be provided to 
protect one user from another and to protect the system from the 
users. 

An objective of SL is to fulfill the above requirements by, among 
other things, designing a system with self describing data. To 
this end, attribute examining hardware should enhance bcth 
security and system integrity and fulfill the additional 
requirement of making it possible to restructure data without 
invalidating programs. 

The design of 31 must allow more efficient implementation with 
LSI than would be possible if the high-level source language were 
translated to a low-level machine language implemented with LSI. 

SL must be extendible to accommodate new operators, new data 
types, and new devices. It must also enforce constraints that 
encourage more disciplined use. 

SL must accommodate programs tnat expioxt new marxet areas: 
particularly data base systems, data communication systems, 
transaction-based appiications, ana interactive use. These new 
areas must be accommodated without losing ground in what will 
continue to be a major marxet, batch computation in established 
applications. 

ATS must emulate 3ystem/37u with twice the cost/performance. 
»ihen the customer maxes the transition to native mode AFS, there 
must be a four to one gam m price performance over System/3 70. 
The customer must be able to maxe the transition in a piecemeal 
fashion. The part of an application that has been translated- to 
AFS native mode must exhibit AFS properties; tor example, 
translated parts must exhibit user security and system integrity 
that is unachievable in 3ystem/37o. 

To aid a customer’s transition, PL/1, FORTRAN, COtfOL, RPG, and 
APL as executed by AFS must meet standard specifications for the 
languages. 


1.1.4 D esig n Principl es 


SL has been constructed with a number of specific design 
principles m mind. They are each discussed in Section 1.2.5. 
They are; 

Minimum Number ot basic Concepts 
Completeness of basic Concepts 
Rigorous Control ana Access Disciplines 
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Maximum Hardware Design Freedom 
Network Function Transparency 
Bit Code Independence 
Modifiability 
Extensibility 


1.1.5 Basic Co ncept s 


Key Elements o t a high level interlace and or a machine that 
directly supports the interlace, nave been described in several 
earlier reports, such as the McPherson task force report and the 
Endicott HLS Prototype reports. i‘he machine is partitioned into 
functional units for processing, storage management, and 
source/sink and networx communications. The interface includes 
self-describing data, generic operators, separation of storage 
from communications I/O, ana provision for coexistence and 
interaction of data and program material produced ror dissimilar 
architectures (such as System/3/u, System/3, 7090, 140 1, etc.) . 


Producing a design capaole or integrating these xey elements 
requires more than simply defining a particular external 
interface. A formal conceptual foundation must first be erected 
m which it is possible to exhinxt basic elements, structures, 
mechanisms, and key processes with which one can realize and 
prove proper behavior not only lor computational processes, such 
as arithmetic expression evaluation, but also tor essential 
system functions such as coexistence, multiprocessing, data base, 
networks, and dynamic resource management. To date, most of 
these aspects have simply been left lor the system programmer to 
solve. Experience has made it clear that system design cannot 
continue to ignore such matters. This is especially true tor 
systems such as AFS. 


The conceptual foundation tor 3L consists of three basic 
elements: Process, Storage sell, and Object; three basic 
structures: Accessibility Graph, Environment Tree, ana 

Dependency Graph; two classes of basic mechanisms; inter-object 
communications protocol and later-ooject request/response 
handling; and five key processes: translation, expression 

interpretation, symbol resolution, procedure activation, and 
resource management. 


A process designates an algorithmic activity. It consists of a 
motive force called an interpreter, a procedural description, and 
a set of status information called tae PSE (Process Status 
decora). A storage ceii is the basic unit of storage. It is 
identified by a unique internal identifer called a Cali Name, and 
it contains exactly one object. an object is an entity used to 
represent every logical and physical resource or the system. It 
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has an active subeleuent, a process called an Access Machine, and 
a passive subelement, called an owned hesource. Every reference 
to the owned resource is accomplished by activation of the access 
machine. This model permits unxiorm representation and handling 
of all system resources. 

The accessibility graph defines the paths by wmch objects may be 
reached. It contains a subgraph, a tree called the Ownership 
Tree, which defines ownership among objects. The environment tree 
defines the context in which symbols appearing in program modules 
are resolved to particular objects. The dependency graph records 
dynamic dependencies among objects. It includes a subgraph 
called the Activation Tree, ana it is used by resource 
management. 

The names of the basic mechanisms and Key processes directly 
suggest their respective roles. 

by using the above constructs, a conceptual foundation of the 
necessary type has been defined. The definition methods 
developed by the Vienna Laboratory (VDL) were employed to ensure 
formal completeness. SL represents a particular interface 
definition witnia the conceptual framework. 


1.1.6 System Conc ep ts 


Part 3 of this document discusses the manner m which the SL 
conceptual foundation serves as the basis for a total operating 
system that meets FS market requiremeats. Of particular concern 
has been consideration of resource management, user environment, 
system control, and functional capabilities. 


1 

* CA+J 

l eo*iFuer^ 


The A FS system effects a modular handling of user environments. 
All resources of the system, including ports to the outside 
world, are owned by the resource manager. The operating systems, 
defined as subsystems in SL, through which a user may wish to 


Resource management encompasses handling of both nonunigue 
resources such as storage ana unique resources such as particular 
data elements. A resource management policy is adopted which 
will ensure completion of ail jobs submitted to the system. The 
sy stem can be so structured that it is possible to prove that 
r esource c onflicts nev er occur in vital portions of the system. 
Errors 'occurring elsewhere are prevented from propagating to 
other parts or the system. Individual users are offered the 
option of avoiding deadiocrs altogether by stating resource 
requirements in advance, or of dynamically requesting resources 
at the cost of possibly having to oack out of deadlock 
situations. 
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avail himself of APS facilities are also owned by the resource 
manager under the subsystem landlord. Each subsystem claims, and 
is allocated if available, a package of resources which it may 
control and allocate to the user vra its own subsystem resource 
manager. Seme operating systems may be granted a "semi-permanent" 
(e.g. "I PL’* to "shut-down**) status in the system, existing for 
long periods of time and servicing many users; such dedicated 
subsystems say have direct, impircit control over a set of ports. 
Thus, a user entering the system via any of these ports sees only 
that operating system and reels as though he were running on that 
subsystem's host architecture; this is txie iogical eguivaient of 
virtual machines ana permits users of, e.g. Go/370, to run as 
though they were on System/J70. Users entering the system 
through ports not directly controlled by dedicated subsystems 
first encounter the initial interpreter, through which they may 
reguest the creation of a free subsystem ror their private or 
shared use. The subsystems thus established are transient and 
are granted access to resource packages minimally including the 
active port and the user's flies. Jnce running unaer a subsystem 
iSL itself is an example) , the user may request the dynamic 
creation of additional subsystems for concurrent or consecutive, 
interactive or natch, dependent or independent, execution. A 
user job, in the classical sense, is thus initiated at port 
sign-on times and terminated with sign-off; dynamic subsystems 
created in the interim may become jobs at the user's explicit 
request. 

The system control structure is rased upon partitioning system 
activity into functional and server configuration levels. Work, 
flow on the functional level handies initiation, coordination, 
and termination of communication, data entry, data retrieval, and 
computation functions. Gn the server level, wnicn is beneath the 
3L level, control is concerned wita orderly flow of work, through 
the system, including control ana synchronization of both logical 
and physical resources. 

Consideration of system functional capabilities includes 
particular concern regarding data base, data communications, and 
coexistence. 

SL oojects and data structures provide convenient representations 
for the data aggregates and indices required for either 
ring-structure or entity-set data organizatrons. Access machines 
and the accessibility graph can be used jointly to enforce 
privacy and security. 

At the SL level the user aeais with processes involving data 
communications by use of objects known as Ports. The access 
machines of Ports provide the bridge to deeper levels of 
communication control. The deeper control levels include one 
which performs device indepeuuent formatting, and another which 
handies device function dependent and inter-system protocols. 
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Data tranmission protocols tor line control ana network (path) 
management are handled in the communications unit beneath the SL 
level. 

The access machine also provides a possible basis for coexistence 
and interchange of (virtual) uevices and other systems written 
under differing architectures. The access machine is a process 
which is activated whenever a reguest is made upon the object of 
which it is a part. The interpreter and procedural description 
of an access machine need not be or the same architecture as the 
process making a reguest upon the access machine. SL code can 
therefore call System/370 code in a rigorously disciplined 
manner, and vice versa. This mechanism also enables one software 
subsystem to access data in another, even if the subsystems have 
different architectures. 


1.1.7 The External Int erface . SL 


Part 4 of this document describes the basic infix form of the SL 
language. it is .this form which constitutes the primary 
man-machine interlace cf the AiS system. Each SL function is 
described separately, along with examples of its use and 
discussion of its side-effects. (This level of description of SL 
is only partially complete m Edition 3.) Examples of 
translation of high level iang uage constructs to SL are also 
presented. 


1.1.8 A L ogi cal Imple m entati on 


Part 5 of the document presents a logical implementation of AFS. 
The definition methods developed by the Vienna Laboratory (VDL) 
were employed, in order to insure formal consistency and 
completeness. This approach turned out to be particularly 
effective for this level or design won. The presentation in 
Part 5 is an English transcription of the formal implementation 
rather than one whicn utilizes the VDL notation. 

The logical, implementation of AFS describes the wiy the system 
operates on an abstract machine which models the concepts SL 
presents to an AFS machine language programmer. Any physical 
implementation that produces tne same observable behavior is a 
proper concrete representation of AFS. System designers are free 
to realize the AFS system m tne most economical fashion for each 
particular mar&et. Slavish copying of the logical model would 
probably result in an inferior pnysrcai impiemeutatroa. Such an 
implementation, therefore, is not recommended. 
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1.2.1 R ational e of the APS Sy stem 

There is considerable evidence that a Von Neumann architecture is 
inadequate for future IBM systems; such an architecture is a 
poor target for compilers, the coding conventions are inefficient 
in the information theoretic sense, and the units of work encoded 
are not optimal for either large or small machines, furthermore, 
the property of data independence, waictt is clearly required for 
future systems, is impossible, or at best prohibitively 

expensive, with an architecture m which attributes of data are* 
sprinkled throughout every instruction that references tne data. 
There is also a serious question as to whether a system based 

upon Von Neumann instructions can guarantee the security and 

integrity that future systems must provide. 

Another problem that must be corrected is that present 
hardware/software systems require the user to understand much 
more than he needs to know to ao his work. A solution to this 
problem in a limited context has been provided by certain 
conversational systems like JuSS, CPS, and nPL. In these 
systems, the user is not required to learn unrelated languages 
like machine language or JCL in audition to the language in which 
he writes his program. furthermore, he nas good conversational 
access to what is going on; ir he does something wrong, he is 
likely to find out forthwith. Nith new architecture, these 
advantages will extend to the tuii range of problems that 

computers solve without incurring the performance penalty of a 

software interpreter. 

During the past decade, considerable practical and theoretical 
work on programming languages uas been done. Although centered 
around language, this work nas analyzed structures that are 
fundamental to all ions of computation; the structures are 
common to many types of languages and appear throughout operating 
system design. The time is ripe, therefore, to focus upon these 
basic structures, to implement them directly in hardware, and to 
construct tne architecture of an entire system upon the 
foundation they form. . 
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1.2.2 Interface Level s 


At present, five basic architectural levels have been identified; 

1) Physical Components 

2) Hardware Boxes 

3) System Control 

4) System Language, SL 

5) General User 

This document discusses tae logical aspects or tne interlace 
between levels 3 and 4. The ATS System Architecture, of course, 
must define the details of all interfaces. Several observations 
should be made on the interface between SL and System Control. 

An AFS system, logically, maxes available to a user through the 
SL interface a set of system services m data communications, 
data eatry/retrievai, and data manipulation and computation. 
Beneath the SL level, the control and synchronization of system 
work flow is under the control or a System Control program. The 
System Control program is architected to consist of a number of 
functional control modules. Terminal Control, Data Communications 
Control, Data Control, Monitor Control, and Command Control. The 
Command Control module has tne responsibility to coordinate work 
flow activities on both the logical and physical levels. On the 
physical level System Control functions are mapped onto a 
physical structure which consists of three basic engineering 
subsystems, PPS (Program Processing Subsystem), SMS(Storage 
Management Subsystem), and SSS(Source/Sink Subsystem). Each of 
these units requires its own logical control program, which will 
be called an ECP (Engineering control Program). The SL/System 
Control interface is common across aii AFS installations. 
Within the System Control lever, the SCP interacts with the 
interface provided by the respective ECP’s. This interface will 
be called the El (Engineering Interface) . 


1.2.3 L ogical and P hy s ical In terfa ces 


In early computer systems, logical and physical interfaces were 
identical: programming manuals included a rough sketch of 

hardware organization, describing registers, data paths, and CPU 
clock cycles. In System/36u, IBM introduced a family of 
computers with identical logical interfaces, but totally 
different physical organizations and data flow. Software 
developments removed the programmer even furtner from hardware; 
with pseudo-devices in HASP ana virtual machines in CP/67, 
programming interfaces became purely logical, with no direct 
relationship to physical aevices. 
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A lessoa from history shows tne importance or separating logical 
and physical interlaces; On tae IBM 704, ail I/O went through 
the iSQ register in the CPU; a programmer couid overlap I/O and 
computation only by complex programming techniques involving 
delicate timing considerations. the IBM 709 added channels to 
allow I/O transfers to proceed without interfering with 
computation, hut eac h type of I/O device require d ^ d-iii-exent set 
cf co ntrol instruc tions. System/s&u "simplified the logical 
interface by adding control units tnat responded to the same type 
cf command for an entire class or devices, but the proliferation 
of channels and control units increased the number of hardware 
devices and hence total system cost. To reduce cost, small 
models like System 360 Mod lb used CPU logic to perform the 
functions of channels and control units. After a decade of 
progress, physical interlaces on the Mod lb were the same as on 
the 704, but logical interfaces were totally different: because 
of functional differences net ween I/O and computation, computer 
architects had defined logical interfaces that separated channels 
and control units from tne CPU; on the assumption that every 
logical interface requires a physical interface, they had 
designed different hardware devices for every functional unit; to 
improve cost/performance, engineers eventually found ways of 
doing all the functions on a single unit. The moral is that 
logical interlaces are programming aids, physical interfaces are 
engineering approaches to better cost/performance, and any 
similarity between the two is purely coincidental. 


The APS project involves a critical analysis ana redefinition of 
aii interfaces in an information handling system: the 
programmer's interface should ne a purely logical one with ail 
the aids that can simplify his task and with no housekeeping 
details; the physical interlace should be designed for optimum 
performance at a given cost with no unnecessary constraints from 
the programming interface. 


1.2.4 F acili t ie s Beneath the Logica l Interf ace 


Before considering what 
us contemplate the stat 
For our hardware, assua 
features and a modified 
a PL/I program using di 
modified CP/67 running 
management on such a 
program must manage tr 
disk file. Beneath t 


features future systems should have, let 
e into which current systems have evolved, 
e a hypothetical Model 19b with relocation 
CP/o7 system to run on it. Then imagine 
sk 1/0 running under OS/360 cunning on the 
on the hypothetical Model 195. Storage 
system is fantastic: First, the PL/I 
ausfers between its own storage and the 
he PL/I interface, tae compiler inserts 


storage management routines to subailocate storage faster than 
OS/360 can with GBTSAIDi and FhLLMAiM. On the next level, OS/360 
allocates space to the program and parcels it out m response to 
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GETMAIN's; it also allocates space on its virtual 2311 disk and 
does housekeeping for I/O reguests. On tne next lower level, 
CP/67 creates the illusion or storage and disx. toe QS/36U: it 
busily allocates space in core, moves virtual pages to meet the 
demand, and conjures up a 2311 out of space in core, drum, and 
2314 disk. Meanwhile, hardware allocates blocks of space in the 
high-speed buffer and moves data to anticipate future use; it 
also allocates space m various registers invisible to the 
programmer: instruction butters, data buffers, and reservation 

stations that effectively replace tne floating-point registers 
with a set of virtual registers. The point of this example is 
that storage management occurs at every level of current systems: 
allocations done at one level are frequently undone at the next; 
most of the allocations are done by software; and storage 
allocation by hardware is about two orders of magnitude faster 
than allocation by soitware. 


As the preceding example showed, storage management by operating 
systems is inefficient compared to management by hardware and is 
inadequate to eliminate further management by problem programs. 
Processor allocation and task dispatching can aiso be performed 
by hardware: super computers like the Model 135 or MP3 have 

built sophisticated multiprogramming algorithms into hardware; 
even a small machine like the Model 23 does hardware dispatching 
every time the CPU converts itself into an I/O channel; and 
multiplexor channels are hardware units designed to appear like 
many channels by internal multiprogramming. A control block is a 
xiad of descriptor that is processed interpretiveiy; Burroughs 
has been building machines lor the past decade tnat do muen, but 
not all, or descriptor processing by hardware. Compilers, 
linkage editors, JCL interpreters, indexed sequential access 
methods, and thousands of problem programs ail do symbol 
resolution and linking, and they could ail do it iuuca more 
efficiently with hardware assistance. Establishing a new 
environment is done by hardware at every change of PSW and 
whenever a CPU becomes a channel; Burroughs systems also use 
hardware to switch environments ror procedure calls. On modern 
systems, these functions occur more frequently than floating 
point multiplies and divides aui are more fundamental to overall 
system operation. For optimum cost/performance, these functions 
should be reduced to a set of primitives that are as firmly 
supported by hardware as floating point arithmetic. 


ftfovtO ft 

7)ff r<*4ljSi7 
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1.2.5 D esig n Principl es 


In order to design a system ot tne greatest possible utility , a 
number of design principles nave Been adopted as objectives. 
Ideally, the AFS system should exhimt properties derived 
directly from these principles: 
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1) Minimum number of basic concepts: Current systems suffer 
severely from constructs chat are seemingly pulled out of 
the air with little regard for consistency or uniformity. 
Every effort is being made to design SL with a minimum 
number of basic concepts. 

2) Completeness of basic concepts: Although few in number, 

the oasic concepts must encompass ail structures required 
for the APS System. Separate operating system or command 
constructs, such as the system structure built around the 
APL language, must be obviateu. 

3) Rigorous control and access disciplines: rue APS design 
must make it possible to prove that system disciplines 
required for security and integrity are enforceable. 

4) Maximum hardware design freedom beneath SL: The design 

should avoid constraining the manner in which hardware 
interprets it since different APS macninas may employ 
quite distinct internal representations. 

3) Network function Transparency: The architecture should 
ensure functional transparency to user application 
programs and most system facilities of the physical 
network location - virtual (co-existent), local, or 
remote - of devices and other systems. Further, it 
should easily allow data and functions to be logically 
transparent to users. 

6) Bit code independence: ine internal bit codes used to 
represent SL should not be defined as part or the 
architecture. A standard representation for compiler- 
output will be defined, but all bit structures within the 
system will be generatau oy execution of SL operators. 
Inverses of these operators are necessary to display 
internal structures for analysis and debugging. 

7) Modifiability: Tae architecture should contain provision 
for user redefinition ot system operators. The user 
should be able to incorporate suitably disciplined 
procedures in place or those normally supplied by the 
system. Architecturally, this requires that system 
primitives are themselves redefinabie m terms of the 
system. Fully generalized, this principle requires the 
architecture to be recursively extensible, 

8) Extensibility: The user should be able to define new 

operators that operate within his own contexts and to 
extend the definition of old operators to new classes of 
data. 
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1.3.1 Levels of Syntax 


Three levels of SL are aiyiuficaut to tae user. These are all 
symbolic iu the sense that actual addresses and other machine 
oriented quantities are not accessible to the user; they are 
only represented xn 5L by symbols. 

Strict SL is a machine onentea level that is most convenient for 
compilers to generate. Basic infix SL has the same operators as 
strict SL. but it has a format that is more congenial for people 
and can be mapped almost one-to-one into strict syntax. 
Following is an expression m strict syntax: 

stow (quotient (sum (A ;b) ;sum(i_;b) ) ; E) 

In basic infix, the example becomes 

( (A+B) + (C + D))->E 
or 

A + B-*- (C+D) —>E 

Extended infix is the most fuiiy developed SL syntax. It 
incorporates basic infix as a proper subset. Extended infix will 
be supported by a software translator tnat will map it to strict 
syntax. The purpose of extended infix is to provide a flexible 
programming tool for those wno wish to work directly with APS 
data structures, 

APL and LISP are expression oriented languages: tae result of 
every operation is a value tnat can oe used as input to another 
operator; consequently, experienced APL programmers often write 
subroutines consisting of a single expression with dozens of 
functions and variables; in LISP, an entire program is normally 
one long expression. The syntax of APL or LISP has both 
advantages and disadvantages: its advantages include simple 
syntactic rules with only one statement type and freedom from 
arbitrary conventions, a context tree structure that allows any 
operand to be replaced by an expression that computes the same 
value, and a consistency that makes programs a subset of the list 
structures allowed for data; a possible disadvantage of such 
syntax is that it sometimes leads to long statements that are 
hard to read. Although long statements may obscure the 
programming style, they arise from the great modularity of 
languages that can combine small expressions in an endless 
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variety of ways, Rather th.au restricting the power of the 

system, APS Will provide a general expression oriented language 
together with programming axes that encourage a clear, 

disciplined style. 

As an example of the power of generalization ana the expression 
oriented structure, consider a program to read records indexed by 
the variable CURRENT from files JOE and SAM and then write the 

smaller of those two records on tne tile TOM indexed by CURRENT. 

PL/I requires the following four statements to perform the task: 

HEAD PILE {JOE) INTO {TEMPI) KEY (C UK BENT) J 

HEAD PILE (SAM) INTO (TEMPI) KEY (CURRENT) ; 

TEMPI =MIN (TEMPI ,TEMPI) ; 

NSITE FILE (TOM) FROM (TEMPI) KEYFROM (CURRENT); 

The first observation we might maxe about these statements is 
that although they perform actions very similar to the fetching 
and storing of single elements of vectors, PL/i syntax obscures 
the similarity. The second observation is that PL/i chops 
expressions into statements that force the user to create 
unnecessary temporary variables as targets of the READ*s. In SL, 
the similarity between indexea vectors and indexed sequential 
riles is reflected in tne language, and the tact that every 
expression has a value allows all four PL/I statements to be 
condensed into one SL statement: 

JOBlCURRENT] min SAM( CURRENT j -> TOtt£CURRENT]; 


1.3.2 S trict Syntax 


Although bit encoding of the machine language is not a primary 
topic of this report, a concrete notation is necessary for giving 
examples and stating definitions precisely. Therefore, ail 
definitions will be stated in a form called the APS strict 
syntax. This form is a direct mapping of the tree structure of 
the abstract syntax ana is isomorphic to the class of bit 
encodings that will be executed directly by hardware. Following 
are production rules for the strict syntax m the ISM standard 
metalanguage: 

group : := _£ s-expr i ; s-exprj ... j£ 

s-expr ::= symbol £arguaeat-iist] J group | constant 

argument-list ::= { s-expr £; s-expr] ... ) 

symbol ::- letter £ letter)digit)underscore] ... 

An s-expr is an expression in the strict syntax. More general 
expressions in the extended syntax are defined by their mapping 
into s-expr*s. A group is a collective object wnose elements are 
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complete expressions; it corresponds to BEGIN-END or DO-END 
blocks in PL/I and to procedure and function bodies. The group 
is more general, however, because it returns a value and can be 
used in place of an ordinary variable or constant; furthermore, 
it has the structure of a list ana can be indexed or concatenated 
with other groups. A complete expression forming one element of 
a group is called a statement; following is an example of a group 
with two statements: 

{stow (sum (sin (X) ; exp (cos (Y) )) ;z) ;sum (difference lA;b) ;C) } 

The first statement saves the result of the computation in Z, and 
the temporary value is discarded when execution moves on to the 
next statement. The second statement computes (A-B+C), waich is 
returned as the value of the group. This form of syntax has a 
structure that is good for compilers, but bad for humans; the 
extended syntax is an infix form that is good for humans and 
directly mappabie by compilers. 


1.3.3 Ext ended S ynt ax 


Although the strict syntax presented above is mathematically 
elegant, it suffers from the LISP unreadability syndrome: it 
uses too many parentheses, prefix notation is harder to read than 
infix, and arithmetic expressions are not written m familiar 
forms. The sample expression given m section 1.3.2 may be 
written in infix form as: 

{sin X+*cos Y->Z;A-B+Cj 

To improve readability, extra blanks and parentheses may be 
inserted, familiar mnemonics like ‘exp 1 may be used instead of 
single character operators, and comments in french guotes may be 
inserted anywhere blanks may appear: 

{sin X + exp cos Y -> Z; 4 A-B + C) «value of group» } 

The extended syntax will also include additional forms that are 
familiar from other programming languages such as if expressions 
and do-loops. Since a group is a list of expressions, an if 
expression can be constructea by indexing. For example, all 
three of the following expressions 

if A=B then X+3->Y else Y-3->X end 


{Y-3->X;X+3->Y}{A = 3j 

A-B select {Y-3—>X;X + 3—>Y j 

can be converted to the strict syntactic form 

selec t (eg (A; B) ; {stow (differ eace (Y ; 3) ; X) ; stow (sum (x; 3) ; Y) } ) 
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1.3,4 Charac t er S et 


The character set for a programming language must be a reasonable 
compromise among many conrlictmg constraints; 

1) Ease or program entry, 

2) Readability, 

3) Use of familiar conventions, 

4) Availability of existing and future I/O devices. 

For good readability and an estheticaliy pleasing text, a large 
character set is important; studies of reading speed show that 
average readers can read lower case text much raster than text 
printed in upper case only, and mathematicians use a large 
character set to reduce long formulas to a size that can be more 
easily encompassed by the eye. API has had considerable success 
m introducing a number of special characters for various 
functions, but rigorous adherence to the convention of single 
character operators leans to absurdities like " 1 circle X” for 
sin(X) and "I-beam 20" for time. A large character set can 
unfortunately introduce problems in program entry; the reversal 
operator in APL requires 5 key strokes--upshift, O, backspace, 
upshift, M—and takes more typing effort that a three-letter 
worn. I/O devices for 88-cnaracter keyboards are common, and 
even iarger keyboards will become practical with CRT devices, 
while limited character devices iixe keypunches will be less 
common m the FS time frame. Nevertheless, character sets with 
about 80 or 90 symbols will still ue more accessible than those 
with upwards of 150 symbols. Thecexore, SL should assume that 
the basic form of input will be with a character set of 88 
symbols, but it should make provision for devices with a smaller 
set and take advantage of future devices with iarger character 
sets. 

The proposal currently being considered for the SL external 
syntax is the set of conventions adopted by PAL; ail user 
defined symbols are either single lower case letters or 
alphanumeric strings beginning with an upper case letter; 
reserved words and system defined symbols are either special 
characters or strings or two or more lower case letters. This 
convention includes the APL conventions as a special case, but it 
also provides an infinite number of words with mnemonic 
significance like sin, cos, time, date, if, and then. 
Furthermore, every special cnaracter would have a corresponding 
symbol like 'sum' for *♦* so tnat devices without that character 
could still use the function; for devices without lower case 
letters, an escape character couia be used to indicate reserved 
words. 
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Thxs part of the manual aescrioes the logical structures that are 
Visible to system programmers ana to user programmers who choose 
to code in Si. Although SL is tue maculae language for AF3, its 
concepts reflect the structures of compilers and operating 
systems much more t&an details or typical von Neumann machines. 

Three characteristics distinguish tue following presentation from 
the principles of operation of other machines: the absence of 
hit representations, a theoretical style of definitions and 
theorems, and the Basic assumption that traditional software 
f unctions ox storage allocation and process dispatching are || uefijisj 
performed at the engineering level. ' 

Chapter 2.1 begins with a discussion of objects: their residence , . ' ( 

in storage ceils and their nature as processes. All the objects 
in the system make up tne object base in which three directed 
graphs embody ali interrelationships: the accessibility graph, 
which includes ail possible paths tor accessing one object from 
another; the environment tree, wiiich defines paths for symbol 
resolution; and tne depenaency yrapa, wnich includes all 
outstanding reguests by objects lor services by other objects. 

Further discussion shows now taese graphs interact with various 
types of objects, program structure, and resource management. 

The final chapter in this part discusses tne built-in functions 
provided with the system. 
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2.1.1 5 toraqe 


A fundamental concept of Air’S xa that all storage internal to the 
system is managed automatically: the programmer refers to data 
and other objects by symbolic names rather than by physical 
addresses. Storage management would extend over levels from 
high-speea registers and monolithic memories up through Comanche 
files, optical storage aevxcas, and even cataloged off-line 
storage such as tape libraries. logically, ail such storage is 
an integral part of the system, distinctions between levels are 
invisible to the programmer, and it is considered almost 
unlimited in size. 

When independent formulations of a problem give rise to similar 
concepts, those concepts probably contain an essential element of 
the problem that is invariant under change of notation or frame 
of reference. Tue problem of distinguishing between objects and 
the mechanism for referencing them is a fundamental one that 
every computer system, programming language, and theory of 
computation must face: in von Neumann machines, a special type 

of data called an address is used to refer to other data; 
although addresses have the useful properties of numbers, they 
are bound so tightly to physical storage that their logical 
properties are inextricably confused with problems or allocating 
storage and devices. in the definition of CPL, Strachey 
distinguished L-values and M-values according to whether the 
value could appear on tne iert or the right of an assignment 
statement; the target or an assignment had to be a value with 
location-like properties. AiGOL 60 can be iormaily defined 
without the concept of storage only because it nas a relatively 
small number of basic concepts; to deal with pointers and to 
formalize concepts of assignment, ALGOL 66 introduced the concept 
of a reference, which is like an address pointing to a cell 
capable of holding a given type of object. In his analysis of 
APL, Abrams distinguishes selection operators and computational 
operators: the value of a selection operator is iinxed to the 

storage of one of its operands and can transmit changes back to 
it; the value of a computational operator has no connection to 
the storage of its operands and cannot transmit changes back to 
them. One of the design principles or AFS is to search for the 
essential elements underlying all programming languages and to 
build a new system upon them; the concepts of object and storage 
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cell are fundamental and require careful definition to support a 
general treatment or assignments, synonyms, ownership, and 
argument passing to functions. 

For defining indices and pointers, storage addresses are useful, 
but the housekeeping they entail far outweighs their usefulness. 
The storage cell in AFS is a logical location capable of holding 
any object or collection of objects, no matter how large: its 
characteristics of a location simplify the definition of indices 
and pointers, but it involves no housekeeping burden because the 
storage management system indices the cell appear as iarye as 
necessary and automatically moves it to any device that may need 
to process its contents. 

Definition: A s torage cell is a iogical location identified by a 

unique ceil nam e. Each storage ceil contains one and only 
one object; there is no upper limit on the size of a storage 
cell. The cell name is an internal identifier (abbreviated 
fid) whose representation is invisible to the user. 

This definition is non-coastractive: it defines a storage cell 
oy axioms or characteristics that are visible to the programmer, 
not by an explicit construction from something more primitive. 
The advantage of non-constructive definitions is that the 
ifflpleaeater has maximum freedom in his choice of representations 
and hardware design. The disadvantage of such definitions is 
that they don* t prove that an efficient implementation (or even 
any implementation) is possible. To remedy that situation, the 
informal notes between definitions will illustrate the abstract 
concepts with a sample implementation; since the illustration 
will not necessarily be the optimum engineering solution, the 
impiementers are free to use any design that satisfies the 
axioms. 

Definition: A buffe r is a temporary storage ceil created for the 

purpose of holding an object until it can ue processed or 
moved. 

Buffers are intimately related to tne mechanism tor passing 
messages between objects such as arguments to functions and 
results from functions: Normally, what is passed is the cell 
name of soma storage cell containing the message; in computing 
X£I], for example, the select function returns the cell name for 
the storage cell containing X£ IJ. however, when the sum function 
computes (A+B), there is no permanently allocated storage cell 
containing the result; tneref ore, the interpreter that is 
interpreting the function obtains a temporary storage cell, 
called a buffer, to hold the result. Buffers correspond to I/O 
buffers in current systems as wall as to registers m the CPU or 
on a pushdown stack. 

A particular implementation of tne storage cell concept is 
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discussed in the System Architecture Manual. The Storage 
Management Subsystem (SMS) described there provides spaces 
identified by unique space numbers; each space is linearly 
addressable by an offset from the beginning of the space. A 
collection of storage ceils can be implemented as a space divided 
into a number of fixed length blocks holding object images, also 
known as DAPGVs (Descriptor And Pointer Or Value). The cell name 
corresponds to the space number and offset to the object image; 
the uniqueness of space numbers guarantees the uniqueness of ceil 
names. If an object imaqe is very large, the block identified by 
space number and offset only aoids part of the image and contains 
the space number of another space holding the overflow. Since 
spaces can be chained together if necessary, there is no fixed 
bound on the size of objects. 


2 .1.2 P rocess es 


The concept of process is fundamental to ail levels of an 
information handling system: CPU, channels, operating systems, 
and external devices. A rationally designed system must nave a 
precise concept of process and of the possible interactions 
between processes. in APS, the definition or process is based on 
the well developed foundation of automata theory and is designed 
to facilitate the implementation or multiprocessing systems. 


Definition: A proc ess is an automaton with a set of states S and 
a set of states W contained m S m which it waits for 
input. Processes can be best described by assuming they 
nave three parts: 

1) A process status record (abbreviated PER) containing 
tne current state, input, and contents of buffers 
used foi working storage. There is a one-to-one 
correspondence between processes and PSR’s. 

2) A proce dur al description that encodes a finite set 
of information defining the states and permissible 
transitions between tnose states. Some procedural 
descriptions may be snared by many processes. 

3) An interp r eter that pertorms state transitions for a 

process: it examines the procedural description and 

the PSR and sets the PSR to its next state. An 
interpreter may be time shared among a number of 
processes, 


The process status record xeeps track of ail information that 
defines the current state of a process. In automata theory, a 
PSR is analogous to the instantaneous description of a Turing 
machine. In a System/360 CPU, a PSR is analogous to the program 
status word together with the contents of the fixed and floating 
registers. In the CDC 7bdO, the exchange jump package is the 
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equivalent oi the PSA. In the Burroughs 6700, the pushdown stack 
together with control words that may be stored in it form the 
equivalent of a PSh. 

Above the SL level, a procedural description could be a read-only 
program. Beneath that level, procedural descriptions may be in 
microcode or hard wiring. The reason for separating the 
procedural description from otner parts of a process is to allow 
a number of re-entrant processes to use the same description 
simultaneously. For primitive objects, tne hardware may take 
shortcuts during high-speed execution and not separate the three 
parts of a process; tor error logouts or responses to a 
diagnostic programmer, however, the system must generate a PSfi 
that effectively represents the current state of an object. 

Tne interpreter is the motive power that causes a process to move 
from one state to the next; it is the logical abstraction of 
active servers like CPU’s ana channels, but is more general since 
it includes software interpreters as well as special devices that 
may be attached as ifP^’s. The AFS logical architecture has 
deliberately avoided the concept of a CPU; instead, the mere 
general concept of process allows tne engineer greater freedom to 
build distributed execution units, special purpose devices, and 
multiple processing units to improve performance without changing 
any logical interfaces. 

The definition of process sets the stage for later discussion of 
wait states, exceptions, ana suspensions: When a process needs 
input, it stays in one of its wait states indefinitely; a waiting 
process is considered asleep, anu sending it input corresponds to 
a waxe-up call. Exceptions are unusual conditions like 
arithmetic overflow or violations ox access rights; when an 
exception occurs, tne process in which it occurs generates a 
message for another process called a monitor and then goes into a 
wait state until it receives a message from the monitor. A 
suspension occurs when the motive force, the interpreter, is 
removed from a process, and tne process naturally stops because 
there is nothing to aaxe it go; suspensions result from time 
sharing the interpreter among many processes so that only one can 
be running at any given time, but tney can also occur when a 
process has run out of money (using too much time or space) or 
when it is stopped because of some other event like an attention 
signal fro® the programmer who started it. 

Processes occur at all levels of a system. When concepts are not 
clearly defined, engineers ana programmers wonting on different 
levels may be unaware that tney are facing similar problems and 
duplicating functions performea on other levels. in System/370, 
for example, there are processes executing in channels and 1/0 
units. In microcode m the CPU, ana at the instruction level for 
subroutines and tasks. The concepts, terminology, and data 
formats at the various levels completely obscure any similarity 
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between these processes: records or processes in channels and I/O 
units are maintained rn channel status words; the record of a 
process at the microlevel is logged out i>y the DIAGNOSE 
instruction; the record of the arcaitecturally defined CPU status 
is in the program status worn and register contents; and the 
record of a process as viewed oy 05/360 is in the task control 
nlock. Not only does System/370 use awkward terminology for the 
various processes, it also uses awkward means for switching 
status: for subroutine calls, the 8AL instruction does only half 

the job since it only modifies part of the PSW and it doesn*t 
save registers. To call a program with different status, an SVC 
instruction must be used with considerable overhead from the 
operating system. The rest of the status, tne registers, are at 
the mercy of the called routine to save or destroy. If the 
called routine is re-entrant, the simple 6AL instruction, which 
takes one microsecond on a Model 65, must be supported by two SVC 
instructions to get and tree temporary storage, at a cost or over 
200 microseconds. In AFS, PSh's maintain the status and working 
storage for ail processes at ail levels. Although data formats 
beneath the SL level are CPU dependent structures and cannot 
therefore be identical to formats above tnat level, the same 
concepts and terminology are used to emphasize the relationship 
between similar problems on different levels of the system 
design. 


2.1.3 Object s 


In AFS, the object is a > generalization from two sources: 
descriptor/value pairs and resource/process associations. 
Descriptors are maintained witn data in data management systems, 
APL, SULKS, ana the dynamically varying parts of PL/I. The type 
field in a descriptor can be interpreted as the name of a machine 
for accessing the value part. Although the few bits that 
describe a floating point number don't exnibit many 
characteristics of a procedure, the generality of an access 
machine or procedure is valuable for complex arrays and 
structures and is essential for tne intricate relationships in a 
large data base. The association of a process with every 
resource derives rrom Dijkstra's approach m T.H.E. 
Multiprogramming System and from Oie-Johann Danl's approach to 
objects in SIMULA 67. Dijkstra associates a process with every 
resource in his system; tne process is solely responsible for 
allocating that resource and acts as a central clearinghouse for 
ali accesses to it. Chapter 2.5 shows that aii objects m AFS 
have the properties of oijkstra's resources and naturally fit 
into a general scheme of resource management. Alan Perils 
suggested that simulation languages might provide a suitable 
basis for an operating systems iauguaye since they have the best 
developed concepts of event ana process; the AFS concept of 
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objects as processes is a geaeraiization of the objects iu the 
simulation language SIMULA t>7. 

Definition: An object is the basic entity in the system; it has 

an active part called an access machin e and a passive part 
called an owned resour ce. Its active part responds to 
reguests by other objects and may in turn generate reguests 
of its own. 

1} There is an input gueue of cell names that specify 
buxfers containing reguests for the object. 

2) The access machine is a process that waits in one of 
a set of states called re ady sta tes when it is ready 
to respond to input reguests. When a ceil name for 
a request appears on its input gueue, it assumes 
ownership of the buffer containing the reguest, 
performs whatever action is appropriate, returns a 
buffer containing the answer, and returns to a ready 
state. 

3) Tne owned resource is data that is accessed only by 
tne object's access machine; for oojects like clocks 
or printers, however, the resource may interact with 
events outside of the system. 

Since this definition is general enough to accommodate 
source-sink I/O devices as well as objects as powerful as a 

Turing Machine, it can include any conceivable device within the 
standard accessing and allocating method. For a floating point 
number, the implementation could specify a fixed length bit 
string as the resource and a few bits to identify a hardware unit 
as the access machine. For I/O devices, tne onject internal to 
the system would be called a port whose resource would be a 
logical connection to the external device ana whose access 

machine could be a hardware or microcodad control unit. Since 
the internal structure of an object is invisible to the caller, 
an object implemented in hardware or microcode on one system 
could be implemented in software on anotner; as in SIMULA 67, a 
software access machine is a procedure that defines a potentially 
infinite class of activations; an object corresponds to a process 
executing iu one such activation; a ready state is a point in the 
procedure wnere the process waits for input; and the owned 
resource is a set of automatic variables used by the activation. 

Logically, all objects are processes; even a floating point 

variable is a process that is normally waiting, but must 
occasionally answer reguests to deliver a value or to stow one 
away. 

Definition; A primitiv e object is one that cannot be constructed 
from other objects in the system; the PSH, interpreter, and 
procedural description that make up its access machine are 
not objects formally defined in the logical architecture. 

Somewhere underneath ail the logical data structures, there must 
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be primrtive Building blocks from which everything else cart be 
constructed by software. aitnough the logical definitions of 
primitive objects are parallel to the constructions of other 
objects, their substructure is visible only to the engineers and 
diagnostic programmers. 

Definition: A r ed ucible object is one that can be constructed 

from other objects; tne PSR, interpreter, and procedural 
description of its access machine are AFS objects that can 
be manipulated ay Si.. 

Primitive objects are defined axiomatically m terms of their 
effects on other parts of tae system. Sometimes, reducible 
objects are defined axiomatically, but most reducible objects are 
defined by an explicit construction m terms of primitive 
objects. All primitive objects are implementation defined; many 
reducible objects are implementation defined, ana others can be 
user defined. For efficiency, reducible implementation-defined 
objects may be built out of nardware or microcode even though 
they can be constructed out of more primitive objects. 
Logically, however, all reducible objects have the same status 
whether they are implementation defined or user defined. 

Definition; Tne primitive object nil nas an access machine with 
only one state; for every reguest, nil returns a copy of 
itself. For operations on lists, nil nas the properties of 
a zero element list. 

In APL/36G, the empty vectors are similar to ail, but they have 
additional type information; the empty character vector has a 
descriptor that indicates that it is of type character, and it 
expands into blanks; the empty numeric vector is of type numeric, 
and it expands into zeros; nn is of type any, and it expands 
into a list of undefined objects. 

Definition; The primitive ooject under has an access machine 
with only one internal state. For every reguest except 
destroy, undef raises an error exception. 

Logical storage ceiis can never oe empty. If nothing else has 
been put in them, they contain an undefined variable object. The 
object nil is a general neutral element; it responds without 
error exception to any reguest, although some functions such as + 
or - may themselves raise error exceptions when given a nil 
operand. The object undef is a general undefined element; it 
always raises error exceptions except when being copied or 
destroyed. 

Primitive objects are so basic to the structure of the system 
that they cannot be constructed by software. Hardware devices 
may not be primitive m tne same sense because a disk drive, for 
example, could be simulated by a software routine that duplicates 
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its interface and uses the storage management system to perform 
the same functions; out there is no sequence of instructions that 
could create a new disk drive in the corner of the machine room 
and paysically attach it to the computer. Therefore, certain 
objects must be built in from tne beginning, and others may be 
attached as the system expands or removed when they fail. As 
long as the physical interface provides circuitry that matches 
voltage levels and makes the uevice look like a procedure, the 
logical interface can make room for it in the object base and can 
define synonyms and access machines that make it respond to any 
protocol expected of it. 

Definition: A port is an object that communicates with the world 

outside the system: its access machine handles the 

interface, and its owned resource is a logical connection to 
a physical device. 

Since ports are objects, taey have the same interface as all 
other objects: they have a well defined status with respect to 
the accessibility graph, environment tree, ana dependency graph; 
and they respond to requests in the same way as other objects. 
Therefore, it is always possible to replace a port with a 
software object that has tne same interface; programmers can 
create logical printers, simulated 2314 disks, ana even simulated 
networks of machines. If a graphic device has an unusual 
interface, the real port to tne device can be replaced by a 
logical port that behaves line a printer, but that contains a 
program to massage control information passed with a request and 
send it to the graphic device in the appropriate format. To make 
network communication more transparent to the user, the system 
will provide identical interfaces for a virtual System/370 
emulated inside the system aua for a real System/370 at the far 
end of a telephone line. 

If communications with a system were m the character format of 
typewriters and printers, the internal representation of an 
object would be of no concern to programmers and could remain 
totally invisible. But since data may be interchanged between 
systems, either conversatioaaiiy or by removable storage media, 
there must be a standard representation of an object taat can be 
recorded on an external medium and reconstructed on a different 
system. This standard representation is called an object image; 
every system is free to use its own internal forms, but they must 
all be directly mappabie to the standard form for an object 
image. 

Definition: An obiect imag e is an external representation of an 

object. The object image has two parts corresponding to the 
two parts of the object: a d escrip tor that specifies the 

access machine and a rep rese ntation of the owned resource. 

1 ) if the object is primitive, the descriptor indicates 
that it is primitive, ana tne representation is a 
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b it string specir ymg winch abject xt is. 

2) In general* the descriptor specifies the complete 

access machine by indicating the PSa (which may 
contain zero bits of information in some simple 
cases), the object image of the procedural 

description or the access machine, and the 

interpreter of the access machine. 

3) If the owned resource contains storage celis holding 
other objects, the representation includes the 
object images of ail those objects. 

4) if the object is a synonym containing the cell name 
of some storage ceil, the object image must contain 
a path name (see section 2.1.5) for reconstructing 
the cell name by indexing from some standard vertex 
of the accessibility graph. 

The object image is an external fora of the DAPOV (Descriptor And 
Pointer Or Value) discussed in the System Architecture Manual. 
Although a DAPOV on a small system may be different from a DAPOV 
on a large one, the object images will be the same for all. The 
object image may be considered as the DAPOV for an abstract 
implementation of AFS; it may turn out to be identical to the 
internal DAPOVs of one or more actual implementations, or it may 
be a compressed encoding of the internal DAPOVs, 

Definition; The object base is tae set of all objects in the 
system. 

The term object base is more general than the term data base 
since it also includes the logical interfaces to hardware 
resources. Because of the generality, all hardware devices have 
descriptors and can have synonyms defined upon them. whenever a 
device breaks down, its descriptor can oe changed to point to 
another device or a software simulator that can replace it. Ail 
of the advantages of late binding therefore apply to devices as 
well as data; instead of doing a SYSGEM for every configuration, 
implementers can provide standard logical facilities, make 
descriptors for non-existent facilities point to substitutes, and 
keep the logical appearance constant as descriptors are changed 
one by one to reflect the current configuration. 

The definition of object given above implies that ail objects are 
serially reusable resources. won-reusable objects can be 
implemented by making the access machine destroy the object after 
its first (or n * th) use; no requests can oy pass this check since 
the object cannot be used except through its access machine, 
de-entrant procedures and tiae-saared devices correspond to a 
potentially ixifinite class or serially reusable objects; by 
subdividing storage, a single re-entrant procedure can provide 
automatic variables for as many activations as requested; by 
subdividing time, a time-slicing routine can provide multiple 
logical devices that all perform the same function as a single 
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physical device. The AFS view oi objects as processes treats the 
problem of resource management as a problem of interprocess 
communication. 

Definition: A request on an object is a triple (T;P; D) , where T 

identifies the request type, P is information proper to that 
type, ana D is the destination or object that is to receive 
the answer. Normally, the access machine ox the object will 
execute tne request and return a result to the object D. In 
some cases, the access machine will cause an event called an 
exception; see section 2.4.1 for a definition of exceptions 
and tne ensuing events. 

Definition: The dep endency graph is a structure defined over the 

object base: If an object x has a request on its input 

queue that specifies an object y as its destination, then y 
is said to depend on x, and (y,x) is an edge of the 
dependency graph. 

Later chapters will bring out implications of the dependency 
graph in resource management, process dispatching, and deadlock 
determination. Chains of subroutine calls form a subgraph of the 
dependency graph known as tne activation tree: if x is an 

activation of a program that carls a subroutine y, then x is 
dependent on an activation of y until it returns. 


2.1.4 Acce ss Machi nes 


Since every object has an access machine, it always has an active 
element available to perform necessary functions. A typical 
function is that of monitoring: During debug mode, the 

programmer may wish to monitor ail accesses to a particular 
variable and tnen perform a specific action such as recording the 
access, calling some procedure, or waiting for abstractions from 
the terminal. For sensitive data, ail requests on an object may 
cause its access machine to check tne identity ot the caller and 
to notify a security officer of an access attempt by an 
unauthorized user. For proprietary software on lease, the access 
machine might aestroy tne object after a thousand uses. All 
these applications rely on tne invisibility of an object's 
internal structure—when an oraiuary variable is replaced by one 
that is being monitored, its normal interface remains uncnanged. 

Definition: An access machine has the following external 

interface; 

1 ) It must have a set of ready states m wmch it waits 
for requests with arguments (T; P; D) ; after 
processing a request, it must return to a ready 
state. 
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2) The argument D specifies the destination for the 

response to the request. 

3) The argument P specifies further information proper 

to the request type, 

4) The argument T specifies one of the following 

request types: 

Authorize : Request to obtain a synonym to the 

storage ceil containing the object (see section 

2.1.5) . 

C opy : Request to obtain a copy of the object. If 

the object say not be copied, the access 
machine raises an error exception. if the 

argument P is mi, taen the entire object is 
copied; otherwise, P must specify some subpart 
to be copied. 

Delete: Request to delete a storage cell of a 

collective ooject. The argument P must be the 
index of tue cell to be deleted (see section 

2.1.6) . Tna ooject contained in the cell is 
not destroyed, out is returned as the response 
to the request. 

D estro y: Request to destroy an object. If the 

object is nou-uestructible, its access machine 
raises an error exception. If it is a 
collective object, it makes destroy requests 
upon ail of its elements before finally 

destroying itself. 

Ev aluat e: Request upon a simple data object to 

deliver a value or upon a more complex object 
to generate a value. The argument P is nil for 
ordinary data objects, but must ba a list for 
functions (see oeiow) . 

Identif y: Request to obtain a description of the 

access machine ana structure of an object. If 
the argument P is nil, the response includes 
ail identifying information; otherwise, P 
specifies the information requested (see 
below). 

I nsert : Request upon a collective object to insert 

a new storage ceil into its owned resource (see 
section 2.1.6) . P specifies the index to be 
mapped onto the new cell by select requests; if 
P is mi, the new ceil has no index. 

Select: Request upon a collective object to map P 
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onto its storage cells: 2 must he a set 
(possibly uil) or elements ia the index set of 
the object; the response is a set of ceil names 
selected by those indices (see section 2.1.5 
for further discussion of indexing) . 

Star t: Bequest upon an activation of a function to 

begin interpretation of the procedural 
description associated with tae function. The 
argument P is a list of objects to be bound to 
the formal parameters of the function. 

Stow; Reguest to stow the value P m the owned 
resource or an object. The access machine will 
either perform data conversions to make P 
comply witn its conventions or raise error 
exceptions if P cannot be converted properly or 
if the current value cannot be modified. 

5) The access machine always reserves the right to tell 
lies about itself and its resource; this right is 
essential to data independence because it must 
aiways ae possible to replace an object with another 
object that may be different in structure, but 
appears the same. 

Definition: In order to specify reguests, a primitive request 

c onstant is defined for each of the reguest types; the names 
of the request constants are formed by audmg 1 s* to the 
corresponding re guest name; auth o riz es, copies, d el etes, 
d estroys , evaluat es, ide nt if ies, inserts, s elects , starts , 
and s to ws. 

Simple data objects like floating point numbers and character 
strings very seldom make requests upon any other objects. The 
objects that normally make reguests are functions: primitive 

functions make reguests upon arguments passed to them in the 
initial evaluate reguest, ana reducible functions are user 
defined programs whose very nature is to make reguests upon data 
objects, upon primitive functions like sum, difference, product, 
or stow, and upon other user defined functions. The following 
definition of function presents the external interface of a 
function: it describes the action of a function as seen by the 

caller or by the rest of the system, but does not describe the 

internal processes and structures of the function. Chapter 2.2 

describes the internal interface of user defined functions and 

the method of constructing them. 

Definition: A func tion is an object tnat responds' to evaluate 

requests by creating an activation and then making a start 
request upon the activation to compute tne value to be 
returned. 
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1) If P is a reducible runction, the activations are 

objects distinct irom F that reside m storage cells 
with distinct ceil names. 

2) If F is a primitive function, its activations are 

not objects and cannot be manipulated by SL 

expressions. ihen the distinction is relevant, 
activations of primitive functions are called 
quasi-activation s. 

3} The argument 2 in tne evaluate reguest upon a 
function P must oe a list of the number of arguments 
required by F. it F taA.es no arguments, P must be 

nil, and P is called n il ad ie . If F taxes 1, 2, 3, 

4, or n arguments, it is called monadic, dyadic , 
tr iadic , t etradi c, or n -ad ic respectively. 

The distinction between a inaction and its activation is 
essential: Since evaluation of a function may tale a long time, 

it would be undesirable to Keep tne inaction tied up and unable 
to respond to any other request during the entire time of 
evaluation; many users on a system may want simultaneous access 
to a function such as a compiler, an editor, or a trigonometric 
function. Even more fundamental are recursive functions whose 
entire structure depends on tne ability for one activation of a 
function to call another activation of the same function. On the 
other hand, it would also be undesirable to have many copies of 
the function, since the code can be snared. Tneretore, a call 
upon a function causes it to spin off an activation which 
contains its own temporary storage, but whicn uses the same 
read-only code as all other activations of tne function: an 

activation is a process wnose PSK is unique to it, its procedural 
description is the read-only code which is shared, and its 
interpreter is the decoding mechanism tnat may be shared with 
other activations of the same inaction as well as with other 

functions written in SL. For consistency, primitive functions 

are considered as activations of hardware or microcoded 
procedural descriptions, but the activations are invisible to the 
programmer since they are defined at a level beneath his view. 

Definition: The triadic function reques t maxes requests upon 

objects and returns the value passed back by the access 

machine ox the object; reguest(T;P;X) maxes a request of 
type T with argument P upon object X. 

The request function provides a general way of making requests 
upon objects. Certain requests, however, occur so frequently in 
specific contexts that special inactions are provided to make 
those requests. 

Definition: The monadic function e valuat e makes an evaluate 

request upon its argument and returns the value that it 
delivers. For any object X, evaluate (X) is equivalent to 
request (evaluates ; mi; X) . 
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Definition: The dyadic function stow maK.es an evaluate request 

upon its left argument to obtain a value P. It then makes a 
stow request upon its right argument with P as the proper 
argument for stow. The value returned by the function is P. 
For any objects 1 ana Y, stow(X;Y) is equivalent to 
request (stowsjevaluate (X) ; Y) . 

Tne stow function is one of two types oi assignment functions in 
AFS. The other assignment is the replace function discussed m 
section 2.1.6. The distinction between stow anu replace is that 
the stow function makes a request upon its target to stow away 
the value, whereas tne replace function makes a request upon its 
target to destroy itself ana tnen replaces it with a totally new 
object. The special character symbol for stow is a single arrow, 
and for replace a double arrow; these symbols suggest the fact 
that the stow function normally changes only the owned resource 
of the target, but that the replace function changes both the 
access machine and the resource parts. 


2.1.5 The Acces s ibi lity G raph 


Previous sections defined objects and requests upon them; this 
section defines the possible patns for reaching one object from 
another. The structure that defines taese paths is the 
accessiblity graph, whica rs a union of two subgraphs; the 
ownership tree that links collective objects with tneir elements 
and chains of synonyms that form links across the tree. Although 
neither the ownership tree nor tne chains ot synonyms allow 
circuits, the accessiblity graph can and must nave circuits to 
support various types or list and ring structures. As later 
discussions snow, the accessibility graph nas tne generality 
necessary for various structures, but it also has sufficient 
restrictions to prevent infinite looping in copying lists or 
resolving references. 


Definition; A synony m is an onject that behaves like a cell 
name; if k is an object and y is a synonym to x, then y has 
the following properties; 

1) The resource of y contains a set called the rig hts 
to x which defines permissible requests on x. 

2) The resource of y also contains either the cell name 
ot the storage ceil containing x or the cell name of 
an object from waich x is accessible together with a 
path name from that object to x (see the definitions 
ox path name and accessibility later in this 
sect ion) . 

3) in response to requests, tne access machine of y 
checks the request ' type; if the type is m the set 
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of rights to x, it passes the reguest to the object 
x; otherwise# it processes the reguest itself. 

Cell names are not objects and caratot be stored and manipulated 
like objects. Synonyms are cell names with an access machine 
that can respond to reguests and with an interlace that gives 
them the same status as other objects. In a sense# synonyms are 
invisible objects because they don't answer reguests themselves# 
but pass requests on to some other object. The rights define the 
requests that can get through to the object that the synonym 
points to. For some reguests not ia the set of rights, the 
synonym raises an error exception; for others, like destroy 
reguests# it may make the response itself, i. e. by destroying 
itself rnstead of the object it points to. 

Definition: The dyadic function authoris e makes an evaluate 

reguest upon its left argument to return a list of reguest 
types and then makes an authorize reguest upon its right 
argument to obtain a synonym with tne list of reguest types 
as the rights of the synonym. If X is an object and L is a 
list of request types, a uthonze (h;X) is eguivaleat to 
reguest (a utnori zes jevaiuate (L) ; X) . 

Definition: Tne monadic function syn makes an authorize request 

upon its argument X and returns a value S that is a synonym 
to the storage cell containing X. The access rights of S do 
not include rights to make destroy and copy requests upon X; 
in response to sucn requests, S destroys or copies itself. 
The remaining ngats in S are the ones granted by the access 
machine or X in response to the authorize request. If a 
request on S is not m tne set of rights and is neither a 
destroy nor a copy request, the access machine of S raises 
an exception. If X is any object and L is a list of ail 
request types except copies and destroys, then syn {X) is 
equivalent to authorize(L;X} # which is equivalent to 
request (authorizes jevaiuate (L) ; X) . 

A data base may sometimes nave synonyms defined upon other 
synonyms; because of tne implicit following or pointers in 
synonyms, there is danger or tne system getting into an infinite 
loop if there is a circuit in tne synonym graph. Since circuits 
or synonyms can only arise as a result of replace assignments, 
the replace function (defined in section 2.1.6} must have 
built-in checks to insure taat the target of the assignment is 
not along a chain of synonyms extending from the source of the 
assignment. If the system is initially without circuits of 
synonyms, then such checks will guarantee that no circuits can 
arise. 

Theorem: If a request of type T is made on an object through a 

chain of synonyms, taea T must be in the intersection of the 
rights of all synonyms m the chain. 
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This theorem guarantees that safeguards placed on a synonym can 
never be weakened by other synonyms with a more.permissive set of 
rights: the rights are a xiud of filter that only permits 

certain types of requests to pass through; another filter can 
reduce the number or types taat pass through, but it can never 
make any other filter more transparent. 

Definition: A me toay m is an object whose resource contains an 

enclosed synonym (see section x.1.7). Since the synonym is 
enclosed, the automatic roilowing of the pointer is 
inhibited, and a disclose operation must be made to obtain 
the synonym. 

Although synonyms are adequate for list processing and data base 
applications, they can’t be used tor pointers in PL/I because 
they are almost indistinguishable from the objects they point to. 
detonyms are objects that are recognizably different from the 
ones they point to and require a special operation to reach them. 
Suppose X is a floating point number, S is a synonym to X, and M 
is a metonym to X; then (S+1) and (X+1) would produce the same 
result, but (M+1) would raise an error exception. The disclose 
function must be used to produce a synonym from a metonym: the 

result of (X +1) could be obtained from M by the expression 
(disclose (M) +1) . 

A synonym is an object that represents or indirectly addresses 
one other object; the most complicated structures that can be 
built out of synonyms are linear chains. Trees represent the 
next level of complexity: a list whose elements may also be 

lists forms a tree; a vector m API is a tree whose leaves are 
one level removed from the root; workspaces in APL are trees of 
heterogeneous objects such as functions, scalars, vectors, 
arrays, and groups; libraries, files, tables, and pools of 
devices all represent collections of objects, which may in turn 
include collections of other objects. In AFS, all these concepts 
are expressed by the general notion of a collective object that 
has other objects as elements; together, the collective objects 
form a tree, called the ownership tree, that includes everything 
in the object base. 

Definition: A colle c ti ve obi e ct is one wnose owned resource is a 

set of storage ceils for containing other objects; the 
collective object is said to own the storage ceils m its 
resource. 


Definition: If x is a collective object and y resides in a 

storage ceil owned by x, then y is an e leme nt of x. 

Definition: An elementary object is one that owns no storage 

cells: it is an element of a collective object, but it has 

no elements of its own. 


IBM CONFIDENTIAL 




42 


BASIC CONCEPTS AND STRUCTURES 


Definition: The ownership relation between collective objects 

and storage cells has the following properties: 

1) No object owns tne storage cell it resides in. 

2) The s yste m root d is a unique object whose storage 
cell is not owned by any object. 

3) No storage ceil is owned by more than one object. 

4) if S is a set or objects containing R and if S 
includes all objects that are elements of objects in 
S, then S includes all objects in the system. 

Theorem: Every object except the system root is an element of 

one and only one collective object. 

Theorem: The ownership relation defines a tree structure over 

the object base: the system root is the root of the tree, 

collective objects are at branching nodes, and elementary 
objects are at ieaves of the tree. Call this tree the 

ownershi p tree. 

The ownership tree provides a basic organization over the object 
base that resembles tne typical tree structure of catalogs. The 
entire Library of Congress catalog is a tree structure: it is 

divided into 26 categories, which are subdivided into 26 

categories, which are subdivided into 10 categories, which are 
subdivided into 10 categories, etc. The table of contents of 
every book is a tree structure; its index is a tree structure. 
The fellow Pages of any telephone book form a tree structure. 
Unfortunately, tree structures are not adequate for all needs: 
almost every index, catalog, and phone book has cross references; 
and in complex cases, the number of basic entries may be far 
outnumbered by the cross references. AFS provides both types of 
referencing mechanisms: the ownership tree includes all objects; 
some of those objects may be synonyms that skip across the tree 

to objects along other branches. Tne union of the ownership tree 

and chains of synonyms rorms the accessibility graph; to the 
programmer, a path tnat follows synonyms can be used exactly like 
a path that only indexes down the ownership tree. 

Definition: The index set of an object x is a set of objects 
mapped onto the elements of x by select requests on the 
access machine of x. The index set of an elementary object 
is empty. 

Definition: A l ist L is a collective object with the following 

properties: 

1) It L has no elements, then L is identical to the 
object ail. 

2) If L has M elements, tnen its index set is the set 

of integers 0, 1, ..., (N-1 ). 

Lists are the most primitive collective objects: they are 
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ordered sets of possibly heteroyeaeuus objects. Although the 
usual formulations ol set tneory consider uaoraered sets to be 
more primitive than ordered acts, linear ordering appears to be 
fundamental for a theory or computation: Common storage devices 
(including tne books in whica set theory is formulated) force a 
linear ordering on all representations or sets. If a set is 
defined in terms of a predicate P, then one might maintain that 
"the set ot ail x such that t'(x)" aetrnes a set without defining 
a representation; in reply, we could answer that only recursive 
predicates are meaning rui m a theory of computation and that 
hence the set must be recursively enumerable. 

definition: The monadic function xlis t maxes an identify request 

upon an object to obtain ns index set: mst(x) is a list 
whose elements are copies or objects in the index set of x. 

it a is a vector in API, (ha j X) is tne length of X, and (IOTA 
RHO X) is equal to iiist(X). In aFS, however, tne index set ol a 
jeneraiized collective object may not be computable from a single 
integer. In JOSS, xor example, the programmer can define a 
vector with valid indices 1, 2, 5, and 9; although RHO of such a 
vector is undefined, the function iiist returns the list 1, 2, 5, 
a. Similarly, APS allows objects indexed by character strings; 
although IOTA and RHO of such objects are not defined, first 
would produce the list ol valia character strings. 

Definition; The dyadic function select taxes an object x for its 
right operand and an element i of iiist(x) as its left 
operand; select(i;x) maxes an evaluate reguest on i to 
obtain its current value and then maxes a select request on 
x with the value ol i as the argument. The value returned 
by select(i;x) is the ceil name of the storage ceil that the 
access machine of x associates with i. 

Tae select function performs tne ordinary operation of indexing 
by integers that is common in many languages as well as the more 
general indexing by character strings ana other objects. The 
method for doing the indexing is left to the implementer: 
integer indexing will probably be done by hardware or microcode; 
indexing by character strings may be done with an associative 
memory, a microcode! search algorithm, or a hashing algorithm; 
indexing by more exotic objects would undoubtedly be done by a 
software access machine. 

definition: An object x is directly, ac ce ss ib le from y if either 

x is an element of y, or x is an element of an object z 
which is directly accessible from y. 

Definition: An object x is indirectly a cces sible from y if 

either y is a synonym lor x, or there exists an object z 
that is a synonym for x and z is indirectly accessible from 

y* 


I Oil COHifibiitf TIAL 






44 


BASIC CONCEPTS AND STRUCTURES 


An object x is directly accessible from y if it is on a branch of 
the ownership tree that nangs down from y. Synonyms in AFS are 
analogous to indirect addresses in conventional systems: x is 

indirectly accessible from y if mere is a chain of synonyms 
leading from y to x. 

Definition: An object x is accessible from y if x is either 

directly accessible from y, indirectly accessible from y, or 
accessible from some object z which is accessible from y. 

Direct accessibility is a relationship isomorphic to the 
ownership tree. indirect accessibility corresponds to chains of 
synonyms and the objects taey point to. The accessibility graph 
is a union of tne graphs for direct and indirect accessibility. 
An object x is accessible rrom y it there is any path from y to 
x, some parts going down the tree ana otners going across chains 
of synonyms. 

Definition: Tne access ibilit y graph is a union of the ownership 

tree and tne cnams of synonyms: (x, y) is an edge of the 
graph ii either x is a synonym for y, or y is an element of 

x. 

The accessibility graph will have circuits whenever there are 
ring structures or general cross references. Consider a 
structure of collective objects, each with four elements: the 
first element is a synonym chat points forward to the next 
object, the second element is a synonym that points bacxward to 
the previous object, ana tne remaining two elements are data of 
some sort; then suppose that tne objects are .iinxed in a ring so 
that tne last object is considered tne predecessor or the first: 
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Consider the following example: 



Suppose a philologist named doe has a data base consisting of 
ancient hear Eastern texts. Each text could he a collective 
object whose elements are lines; each line would be a collective 
object whose elements are words. Although the division of a text 
into lines and words is straightforward, there are many ways of 
grouping texts into larger collections; one way is to put all 
Sumerian texts in one collective object, ail Babylonian texts in 
another, and so on for AJcxadiau and Uyaritic; another grouping 
would put all texts on myths and legends from all the languages 
in one category, all hymns in another category, codes of law in a 
third, and business records in a fourth; many other bases for 
grouping are eguaily possibie--chronoloyical, geographical, etc. 
By means of synonyms, the accessibility graph can exhibit ail the 
relations simultaneously. The diagram above shows part of Joe*s 
data base: The node labeled JOE is a collective object with 
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elements whose indices are •LANGUAGE*, ‘CATEGORY*, and ’SEARCH*. 
Under the collective object JOE.LANGUAGE are collective objects 
tor eacn language Joe as working with; under each language are 
the texts written m that language. But it Joe is doing a 
comparative study oi myths in Sumerian and Babylonian, he may 
bind it easier to use JOE.CATEGORY . MYTB, which is a collective 
object containing synonyms to ail the texts that relate myths in 
any of the languages. in this example, MYTH.P is a synonym for 
BABYLON!AN.F, LAW.S is a synonym tor BABYLONIAN.E, and HYMM.U is 
a synonym for SUMERIAN.B. Tnererore, the node a is directly 
accessible from the nodes SUMERIAN, LANGUAGE, and JOE, is 
indirectly accessible from tne none U, and is accessible rrorn the 
nodes HYMN and CATEGORY. 

The relations expressed by synonyms do not have to be built into 
the structure irom tne beginning; when Joe adus a new text to 
his collection, he can insert it under tne appropriate language; 
at any later time, he can define synonyms lor it in any existing 
categories or even define new categories. Some texts may beicng 
to several categories: SUMERIAN.A can be accessed via synonyms 
MYTH.R or HYMN.V. And in ali cases, a running program does not 
need to xnow if it is accessing an object directly or via 
synonyms. For even greater flexibility, Joe can hire a computer 
science student to write some user-defined access machines to 
create special objects that nave the same interface as ordinary 
collective objects, but that execute elaborate search procedures. 
For example, the object SEARCH may loos, exactly like an ordinary 
collective object; but internally, it has synonyms to LANGUAGE 
ana CATEGORY and has an access machine that searches down those 
trees. If Joe wants to find tne text ot a myth about Gilgaiaesh, 
he could request S EARCH.MYTH.m 1LGA MESH.TEAT; then the access 
machine would look through ail the texts accessible from the node 
MYTH to tmd one about Giigamesh. 

if x is a collective object, its index set must have enough 
indices to select every element or x. If y is an element of x 
and n is the index that selects y, then n is called a simple name 
for accessing y from x. If y happens to be a synonym for seme 
other object z, then n is also a simple name for accessing z from 
x, because operations on y are automatically passed on to z. In 
the above example, 'A* is a simple name for accessing A from 
SUMERIAN, and * V* is a simple name for accessing A from HYMN. If 
x is accessible from y by some complex path, there must be a list 
oi simple names for eacn stage or tne path. In the example, A is 
accessible from JOE by taree different path names: 
LANGUAGE.SUMERIAN.A, CATEGORY.MYTH.R, and CATEGORY.HYHN.¥. This 
example does not show any circuits in the accessibility graph; 
but when there are circuits, there are an unnite number of 
paths and hence path names for accessing some objects. (Note; 
this example used unique simple names for every node to make the 
discussion easier to follow; m general, elements ot different 
collective objects may nave tne same simple names without causing 
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ambiguity.) 

Theorem: If x is au element of y or if x is indirectly 

accessible from some object z w men is an element of y # then 

there exists an element a in the index set of y such that 
x=select (n ; y) . Cali n a simple name for accessing x from y. 

Definition: A path from an object y to an object x is a list of 

objects, the first of which is y and tne last x; from an 
object u in the list to tne next object v, tnere must be a 

simple name for accessing v rrom u. The list of simple 

names is called the path name from y to x. 

Theorem: If x is accessible rrom y, tnen there exists a path 

name from y to x. 

The path names provide a way or indexing down tne ownersnip tree 
and skipping across the synonym cnains. Before using a patu name 
for accessing an object x, tne system must find tne object y from 
which x is accessible by tnat name. The environment tree 
described in chapter 2.3 defines a searen procedure for finding 
the starting point from wnicn the path name leads to the object. 
When a program is executing, tne interpreter resolves names by 
searching up the environment tree until it finds a node that 
recognizes eitner the entire path name or at least tne first one 
or more simple names in it; tnen the interpreter can make select 
requests with the remaining simple names until it reaches the 
object x. 


2.1.6 M anip ula ting Sto rage Ceils 


dost operations on objects maxe requests on tne access machine of 
the object. Certain operations performed on collective objects 
are intended to modify tne storage ceil containing an element. 
Althouyh such operations are intended for manipulating storage 
ceils, they can nave side effects of destroying an object or 
moving it to a new storage ceil. 

Definition: Let x be a collective object, and let i be an object 

which is not in tne set liist(x), but which is acceptibie to 
the access machine or x ror addition to inst(x). Then the 
dyadic function i nsert maxes insert requests on a collective 
object to insert a new storage cell and index: if x already 
has i m its index set, insert (i;x) raises an error 
exception; otherwise, it has tne side effect of adding a new 
storage cell to the resource of x, placing a copy of undef 
in the new ceil, adding i to iiist(x), ana causing the 
access machine of x to map i onto tne new cell. The value 
returned by insert (i;x) is identical to tne value of 
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select (i ; x) . 

Definition: The dyadic function delete maxes a delete request on 

a collective object to remove a storage cell from its 
resource and to remove the index to that ceil from its index 
set; delete (i;x) has the side effect of removing the storage 
cell containing xj. lj from the resource of x and of removing 
i from ill st (x) . Tne ceil name of the old ceil may not be 
used to identify any other cell ever to oe created in the 

system. The value returned by delete (x;x) is the object in 

the storage ceil before tne ceil was deleted. 

Every function returns a value; the value of insert is useful as 
the target of an assignment for initializing tne new object; the 
object returned £>y delete is usarui to allow a ceil to be deleted 
and its contents moved somewhere else in a single statement. If 
the expression delete (i;x) occurs alone in a statement, the cell 
containing xj. i J is deleted by the function delete, and the value 

of x£i] is destroyed when execution moves on to the next 

statement. 


Definition: Tne monadic function remove removes tne contents of 

a storage ceil without deleting the ceil: remove (x) has the 
side efiect of placing a copy of undef m the cell 
containing x; the value of remove(x) is the old value of x 
unc hanged. 

Definition: The dyadic function replace destroys the object 

contained in a storage ceil and replaces it with a copy of 
another object: replace (x; y) maxes a copy request on x to 
maxe a copy of itself, maxes a destroy request on y to 
destroy itself, and places tne copy or x m the storage ceil 
formerly occupied by y. it y refuses to destroy itself, it 
remains unchanged, and an error exception occurs, it y is 
indirectly accessible from x, tnen an error exception 
occurs, and the target is not cnangea. The value of 
replace (x; y) is a copy of x. 

Theorem; No circuits or synonyms caa arise by execution of 

replace; any attempt to form such a crrcuit raises an error 
exception. 

The replace function is a type ot assignment used primarily for 
moving objects and placing initial values into new storage cells; 
its use in initialization is the basis for executable declaration 
statements. For normal assignments, the stow function makes a 
request upon the access machine of an object to perform the 
action and maxe necessary conversions. 

When a storage cell is aeieted, synonyms and metonyms contaxning 
its cell name are not destroyea; but any use ox them raises an 
error exception. Since ceil names are never reused, there is no 
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danger that a new ceil could oe accessed via invalid synonyms. 
The four functions insert, delete, remove, ana replace have 
important side effects on synonyms: suppose x is a collective 

object whose i*ta element is y; tnen tne statements 
(i delete x; i insert x] 

reave a copy of under whose direct accessibility is the same as 
y's, but whose storage cell aas a new cell name that is different 
from the cell name in previous synonyms to y; the operations 
remove(y) and replace (undef ;y) cause the undefined object to have 
the same accessibility as y, even for synonyms. If y is a 
collective object, any storage cells it owns are part of its 
resource and are moved with it; consequently, any synonyms to 
elements of y remain pointing to the same values even though a 
synonym to y itself may point to a copy of ail in the old storage 
ceil. 

Theorem: Let x be an object directly accessible from yj_ i ] and 

indirectly accessible from z. After the operation 

delete(i;y) or remove(y) is executed, but before the object 
yi.i] is destroyed, x will still be indirectly accessible 
from z. 

These definitions can be implemented efficiently: removing an 

object involves moving a single descriptor from a space and 
replacing it with a descriptor tor under; tne rules for synonyms 
to elements of a collective object follow immediately from the 
fact that the space containing tne elements is not changed. 

The function replace is defined as maxing a copy of its left 
argument; in a later section on program execution, tne copy rules 
are modified to eliminate unnecessary copies. In particular, no 
copy is required when tne object is the result of certain 
functions, which include remove and delete. Therefore, the 
following expression does not destroy the object A.B.C, but 
simply invalidates aii its old names and renames it H.F.G: 

replace (delete (* C • ; A. B) ;insert ( *G *; R. i ')) 

In infix form, the above expression may be written: 

* €• delete A.B => ('G 1 insert S.F) 

A major advantage of tne current design is that it has the 

flexibility or general list processing systems without the 
overhead of garbage collection or reference counts. Systems like 
LISP and SNOBUL keep data available as long as there is a 

reference to them; although such a property is oiten convenient, 
it seriously impairs eiriciency: In LISP, for example, the 

standard method of garbage collection is to stop aii computation, 
start at the topmost node ox tne system, and trace aii data 

elements to see if any are unreferenceabie; only after ail nodes 

have oeen traced can the system throw any data away, and only 
then is there any space to resume execution. The method of 
reference counts replaces massive garbage collections at 
infrequent intervals by increments and decrements to a count 
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field whenever synony ms are coaxed, and erased. Although ®ost 
objects have a count field of one, all objects must maintain such 
a field with provisions for letting such values grow arbitrarily 
large. On a storage hierarchy system, reference counts can 
oecoae guite inefxicient since a local action of copying a 
pointer can require the reference count of a distant ooject to be 
modified. The APS approaca is to destroy objects upon explicit 
reguest and to allow synonyms to destroyed objects to become 
invalidated; for ordinary FORTRAN and PL/I programs, this 
approach rs the most eriicreni. If an application requires 
reference counts, they can always oe added by causing the access 
machine of a collective object to keep counts of references to 
its elements, to issue special synonyms that report back whenever 
they are copied or erased, and to delete the elements when their 
reference counts go to zero; thus, the power is available when 
needed, out most objects don't nave to pay for rt. 

Much of the library and cataloging facilities or current systems 
can be nandled oy the functions introduced so far; The DD cards 
rn OS/360 are used to create synonyms between external and 
internal devices; tor example, rt SYSOUT is the name for a 
collective object whose elements are logical output devices and 
if A is the index for selecting logical printers, then the DD 
card 

//STSPEI NT DD SYSOUT=A 
is equivalent to the expression 
syn SYSOUT.A => SYSPRINT 

In OS/360, DD cards also speciry physical characteristics of 
devices and request a type of allocation such as snared use or 
exclusive use for modification; in APS, physical parameters are 
totally unnecessary, and the system provides much finer control 
over dynamic resource allocation (see chapter 2.6). In APL/360, 
system commands are outside or the language and cannot appear in 
functions; following are tne APS iorms of some APL system 
commands: 

) LOAD 10 LOGIC Libia. nOGi»_ = > Current 

)SAVE 10 LOGIC Current => Libia.LOGIC 

) CLEAR ClearWS => Current 

)ERASE JOE SAM delete JOE; delete SAM 

) COPY 10 LOGIC WPP Libia.nUGIC, WFP => (*«PP' insert Current) 

)LIB liist Mystuff -> SYSPRIMT 

The APL/360 system makes copies of workspaces because it has no 
way of sharing read-only objects and no way of defining synonyms 
to objects in other workspaces. Under APS, a subsystem would be 
free to make copies or define synonyms as it chose. 


2.1.7 S tructur e 


The elements of a general collective object have only one thing 
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in common: tney reside rxi storage cells that all have the same 
owner. Special types of corrective oojects may impose mere 
conditions either on the elements or ou the admissible index set. 
Typical conditions restrict the raaex set to integers, pairs of 
integers, or character strings; other conaitions restrict the 
elements to have the same access machines or representations, 
although conditions restrict generality, they may improve 
efficiency and simplify enumeration of all elements. If all 
elements have the same access machine, the descriptor of the 
entire collective object need speeixy the access machine only 
once for all elements; such savings are especially obvious for 
nit vectors. 


2. 1.7. 1 Lists 

we have already defined a list in section 2.1.5. A list is a 
member of a special class oi collective objects with particular 
index sets. The indexing capability of SL provides a mapping 
between a set called the index set and a set which comprises the 
objects in the storage cells of a collective object. The 
elements of the index set are called index objects. As the use 
of the word "set” implies, no structure is imputed to either 
set ny the indexing mecnamsm itself. The most primitively 
structured collective object is the list. A list is a collective 
object whose index set is the set oi integers less taat N for 
some integer N. For example, a list of ten objects nas for its 
index set (1, 3, 5, 1, 7, 4, x, 6, 3, 6). A list in particular, 

and any indexed object in gaaerai, acguires its structure, if 
any, from the inherent structure or the indexing objects 
themselves. This structure must come from something other than 
indexing. In the case of the integers, initial segments of which 
are popular index sets, that structure is provided by the 
arithmetic functions which apply to them. These operations, 
ultimately definable in terms of the Peano postulates, are the 
oasis for most index sets. Accordingly, we may clarify the 
definition of a list to say taat a list is a collective object 
whose index set is an initial segment of the integers. We intend 
to imply that the ordering oi the integers is a part of the 
definition of a list. For convenience, we introduce the 
following 

Definition; A p rimiti ve ind ex set is an initial segment of the 
non-negative integers. 

Usually the term "index set” will be used in place of 
"primitive index set" wnen tna context permits. Lists form the 
only special class or collective objects which is primitive to 
the system. There are no restrictions on tae elements of a list. 
They may be scalars, closures, arbitrary collective objects, or 
other lists. 
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2.1.7.2 Structures 

Since the elements of a collective object may themselves be 
collectives, it is possible to ourld txered structures of 
arbitrary complexity ana indexing depth. It is useiul to have 
some definitions to talk about these objects. 

Definition: A st ruct ure is a collective object some subset of 

whose owned objects is composed of collective objects 
together with all objects accessible by iterated indexing 
fro® the given object. 


Definition: Au indexed struc ture is one ail of whose collective 

objects are indexable. 

Definition: A list struct ure is a structure all of whose 

collective objects are lists. 


Definition: The shape of a list is tne number of elements in it. 

Shape is a general term Which also applies to arrays. When 
referring to lists or to vectors the term length will sometimes 
be used. One of the important characteristics of a structure is 
the number of tiers that nave been defined. One can retrieve any 
one of the elements of a list witn a single indexing operation. 
To specify an element of a list oi lists, tne indexing operation 
must be repeated. 


Definition: The depth or a structure is the maximum number of 

times the indexing operation can be performed on the 
structure before reachiuy a scalar or an object already 
reached. 

A scalar aas depth zero. A simple list aas depth one. One can 
simulate arrays at the programing level with list structures of 
depth two, ie,, with lists or lists. 


One may wish to define a depth two structure of lists whose 
elements are indexable. Unfortunately, the depths of these 
elements will be added to that or the structure and any attempt 
to datermrne the depth wrtn ocaruary functions will yield the 
wrong result. To handle sucn situations tne encapsulate function 
is provided. It conceals any arbitrary structure within a scalar 
so that it can be placed in a structure without increasing its 
depth. The original structure can be recovered by using the 
uncover function. 

For convenience in deiinmg the locate fuactron lor lists we 
introduce a related type or indexed object. It is not primitive 

to 3L. 
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Definition: A pse ud o-list is an ooject whose index set consists 

of integers. 


2.1.7.3 Arrays 

For a number of reasons it is desirable to provide indexing with 
an arbitrary number of objects m a single level of indexing. 
Tne facility is provided by most aign level languages in use 
today. It provides Biucn of tne flexibility of a list structure 
without incurring tne inefficiency of multiple calls on the 
indexing operation to retrieve a single object. Furthermore, it 
is easier to rearrange objects within the structure since it is 
not necessary to shift tnem from one collective object to 
another. 

This desirable facxirty is provided in 3L as in otner languages 
by arrays. In keeping wita the spirit of SL, arrays are 
basically defined in a general way. They drtfer from other 
rndexabie objects in that a rigid rramework has bean provided in 
which their index objects reside. This frameworx. xs defined with 
the aid of a list structure called the base list or the base 
list structure of the array. No restrictions are placed on the 
index objects themselves, or on tne elements of the array. 

Arrays are not primitive to SL. It is tnus an implementation 
decision whether the hardware will construct vectors of vectors 
to describe arrays or not. 

Definition; the ba se list or base fist struct ure of an array, 

A, is a list structure or uniform depth 2, Tne r-th ' 

sablist is called tne r- driuensron index set of A. 

Definition: An arra y. A, of cans. r rs an object whose index 

set consists or lists or length r. The r-tn element in 
each index object list rs chosen from the x-drmensron index 
set of A. The r an a of A xs the shape or its base list. 

An array of ranx r rs car led an r -a rcay. The s hap e or an 
array is a list of the sires of its i-dimension index sets 
for ail applicable r. 

The monadic function roase appxieu to an array produces its base 

list. The composite function shape rbase produces its rank. For 

any array. A, the following identity holds: 

shape A = shape map rbase A. 

The elements of the index set or A are members or tne augment 

outer product reduction of tne base list of a. in standard 
termiaoloyy, this is the Cartesian product reduction. 
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Definition: A vect or is a 1-array. 

Definition: A matr ix is a 2-array. 

tfe shall refer to a vector with k elements and a list With k 
elements as a k- vector ana a K-iist, respectively. In 
particular the empty list and the empty vector are the 0-list 
and the 0-vector, respectively. Mote that a scalar can be 
considered as an array of rank zero as well as a list structure 
of depth zero. 

For a general array there are no restrictions on the elements of 
the sublists of the base list. in fact there is no restriction 
on the lengths of the sublists. For example, the integer 
generator can produce a potentially infinite list, wnich can be 
indexed with any integer. inis list is the only entry m the 
base list for tne corresponding infinite length vector. 

An array may oe indexed by cnaracters, lists, otner arrays, etc. 
It ail the it-dimension maex sets are finite, then tne array is 
finite. If ail the index sets comprise only mteyers, then the 
array is indexed by lists or integers. This is the most general 
type of array usually handled. A particularly important subclass 
or finite, integer indexed arrays is the following: 

Definition: A pr i miti ve array is one m which the index set in 

each dimension is a primitive index set. 

In order to provide the kind or liexibie restructuring through 
indexing whica is avaiiaole in, rot example, Ain we permit the 
substitution of certain arrays within the list which constitutes 
an indexing object. These substitutions define an infinite set 
of structures whicn the select function will accept lor indexing 
arrays. 

Definition: The basis for tne index set of an array is the 

Cartesian product reduction or the base list or tne array. 

This is what is usually called tne index set of the array. The 
function ilist on an array produces the basis of the index set. 

Definition; The compf e te index set of an array is derived from 
tne basis for the index set. For any position or set of 
consecutive positions in an index list may be substituted 
any array. The elements of tne array must be lists of the 
same length as the partial list the array replaces. The 
returned object will be an array. The oase list of the 
returned array is the catenation ox the base lists of the 
participating arrays. 

Since the phrase "basis lor tne index set" is usually shortened 
to "index set", tne word "complete" must be expressed when 
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imported to prevent contusion. The rase list lor an array 
defines its structure iu complete detail even for arbitrarily 
indexed arrays. The information required to determine the index 
structure for a primitive array is much less. it is simply the 
length of the index set m each dimension. The shape function 
applied to an array will return this information m the form of a 
list. The function igenerator applied to a scalar returns the 
index iist for a list of coiresponaiug length. The function 

igenerutor applied to the shape of a primitive array generates 
the index base tor that array ny runctioa drstrroution. 

The relationships between the various types of arrays and fists 
can be described by the results of applying tne various structure 
determining functions to them. The information is summarized in 
the following taole. 
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For convenience in defining the locate function for arrays we 
maxe tne following definition. 

Definition: The inde x o bje ct array; of an array A is the 

primitively indexed array with the same snape as A whose 
elements are the respective index objects of A. 

Note that the relationship between a pseudo-list and its list of 
indices is analogous to that between an array and its index 
object array. 
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The access machine or every object is a process. This process is 
derived from a procedural description by adding some local 
storage and causing an interpreter to begin executing this 
description. This chapter presents the form and execution of 
programs, that is, procedural descriptions written in SI. The 
chapter begins with an overview oi the concepts which are 
important to interpretation and program structure. After that 
the form of a program is given. This is given as a data 
structure in SL. Then, tne constraints that this foca implies on 
the external syntax are given. 

The remainder of the chapter is aevoteu to the interpretation of 
the text of tne program. The interpretation oi an expression is 
developed in detail. The protocols ior calling other functions 
are presented in a form suitable ror using functions written in a 
foreign (non SL) architecture. Then, the interpretation of 
functions with multiple expressions (i.e., statements) are 
described. Finally, various operators tor varying the order of 
interpretation are discussed. 


2.2.1 Key Conce p ts 


This section introduces at an overview ievei tne key concepts 
which are reguired to represent and execute an SL program. 

2.2. 1.1 The Form of the Language 

In SL there are two forms in waich programming may be done: an 
external syntactic form and a machine-oriented data structure 
form. The reason for this dichotomy is that there is no single 
form which is adequate for both human beings and machines, 
humans expect clarity of expression and readability. They oi ten 
find it easier to manipulate programs in textual units such as 
strings. On the other hand, machines work better with fairly 
rigid data structures. Then, the machine can use the fixed 
information to provide a more compact program representation and 
to optimize execution. 

There is, however, another reason for having two representations 
for a program. This is exemplified by LISP. In LISP, it is 
possible to input and dispiay acyclic list structures m an 
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external syntactic form. however, it is also possible to write 
LISP programs to build and modily list structures using the LISP 
functions. Since a program in LISP is a list structure, tins has 
the important consequence that it is easy to write programs that 
write or modify other programs. 

Tne flexibility to construct programs as data structures is very 
important. it makes it possible to write compilers with greater 
ease. It also helps when program modification is required as in 
a sort generator. finally, it allows programs to respond to 
requests by constructing anotaer program to do the work. This 
type of behavior will become more popular as data query systems 
grow. 

The external syntactic form is therefore designed to give the 
best possible human inteirace to the system. it provides 
extensions of the strict machine torm to better support naive 
users. The external form wifi be translated into the machine 
form by an incremental, statement-oy-statement translator whose 
existence can be ignored by most users of tne external form. The 
machine form is defined in terms of data structures which can be 
constructed and manipulated rn SL. It is designed to maintain 
the information needed to do faithful interpretation and to be 
convenient to manipulate. 

Programs are expressed in groups of statements. Each statement 
is a string or symbols. A symbol is one or more characters which 
is clearly delimited. The symbol strings represent infix 
expression m the external form. in the machine form, the symbol 
strings represent the Poiisn prefix form of an expression. In 
either case, a statement is any legal SL expression. Each group 
of statements is represented in tne machine form by a module 
which contains a list of the statements. 


2.2. 1.2 The Execution of the Language 

Program text, even a module, is really only a representation of 
an algorithm description. It is only by executing the text or 
module that the intent or the algorithm is earned out. In SL 
there are a number of steps m the process of executing an 
algorithm or procedural description. These steps form a phased 
history of the life of a module. 

Definition: A module goes tnraugh a number of p hases as it 

entered, prepared for execution, executed and finally 
discarded. These phases m order are: 

Translate: Converting the program into a module. 

Load: Establishing a new copy of the module with its 

associated loan oriented (static) storage in 
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the user's current context. 

Creating an object which contains laioraation 
associating parameter symbols with arguments 
aad contains a new generation or the 
activation-oriented (automatic) storage. 

Interpreting the body or the text at the 
module. 

Possibry reieasrng the generation of automatic 
storage rx it can no longer be accessed. 

Releasing all storage associate directly with 
the loaded morale oeing unioadea. 

At eacn phase tne form of the rnoauie changes. Up to the execute 
phase more and more information is added. After that, 
information is discarded. It is guite possible to use a pause of 
a module as the basis for several different instances of the next 
phase. For example, only a single load is required for many 
different activations of a module. Similarly, a single copy of 
the text of the module can be snarea oy many loans. 

The load and unload phases are developed in detail in Chapter 
2.3. In this chapter the emphasis will be on tne transition from 
the load phase to the activate phase, and onto the execute phase 
and, finally, through the deactivate paase. 

Definition; The transition from the load phase into the activate 
phase and onto the execute phase is called a ctiva ting a 
f unction . 

The process of function activation includes building up a new 
object from the loaded module u y adding some automatic storage, 
passing arguments and causing g ue independent execution of the 
new object. It begins when an evaluate request is made on a 
loaded module. tfhen the activate phase is entered, the 
interpretation of the text is oegun. 

Definition; The inter pretat ion of a function is performed by 
scanning the text of the ruaction module and maxing requests 
on the objects associated with the symoois that are 

encountered. 

In the terms of formal logic, meaning is given to a purely 
syntactic form by associating objects from a universe with each 
of the symbols in the form. Then, the form can be evaluated 
using the rules of combination for the objects associated with 
the symbols in the rorm. In SL, tne symbols are associated with 
storage ceils which noid tne oojects that give the symbols 
meaning. 


Activate; 

Execute: 

Deactivate; 

Unload: 
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Definition: S y mbo l resolutio n is the mechanism which associates 

with each symbol the ceil name of a storage ceil in the 
object base. 

As will be seen m Chapter 2,1, it is possible to separate symbol 
resolution into a number or stages. Each stage inserts 
information which is fixed with respect to ail succeeding stages. 
This factoring of symbol resolution can greatly improve the 
performance of the machine since potentially repetitive work is 
done only once. 

As the interpreter moves through tne module text, it will need to 
Keep some status information in tne PSB ror the activation which 
is being interpreted. One or tne major pieces of information 
that must be saved is the status or evaluating tne operands of an 
operator. Because expressions can be nested to an arbitrary 
depth, an undetermined number or operators may me in tne process 
of operand evaluation simultaneously. Therefore, a special part 
of the P3K is distinguisaea to hold operator evaluation 
information. 

Definition: An ev aiaa nd is a collective object wmch holds the 

information about the status or evaluation tor one operator 
and its operands. Tne evaiaand is part of the PSB, 

An additional portion of the PSA is used to retain which 
statement is currently being interpreted. This corresponds to 
the instruction counter on classic machines. 

Definition; The stat e ment index is a portion or the P3B which 
holds the index of tne statement currently being 

interpreted. if there is no sucn statement, then the value 
or the statement index is under. 

When tne execution of the module text is completed, the 
activation is destroyed. The storage associated with that 
activation may or may not be destroyed depending on whether or 
not references to symbols associated with tnat storage are still 
legai. In PL/1 sucn references are not legal so tne storage may 
be released. However, in ni3P references are legal and the 
storage may outlive the activation. 


2.2.2 I nterna l Program ae pre s entation 


The basic unit of program construction is a stretch or text where 
each symbol in that text uas only one meaning. internally, this 
is represented by a module. 
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Definition: A modul e is a primitive collective object consisting 

of two components: trie module text and tiie dictionary. 

There is one entry m the dictionary for each symbol which 
occurs in the module text, Tars dictionary entry also holds 
the information for symbol resolution. 

The fact that each symbol has only one association within the 
module maxes a module suitable for the minimum unit of 
translation into internal form. The symbols can be factored into 
a separate dictionary, and their occurrences in the text can be 
replaced by offsets into that table. Then, symbols can be 
resolved by associating storage cells with the entries in the 
dictionary. This encoding reauces the size of the program text 
and tne complexity of decoding it. Once program text is encoded, 
however, it is meaningless without the associated dictionary. 
Therefore, whenever program text with symbol associations can be 
selected as a separate unit, tne corresponding dictionary must be 
available to define the meaning of offsets in the encoded text. 

Definition: The die t ionary is composed of three component 

structures: the symbol table, the linkage table, and the 

attribute table. There is a 1-1 correspondence between the 
entries of each table. The symbol table nas the character- 
representation of tne symbol. Tne corresponding entry m 
the linkage table nas the association (it any) for the 
symbol, and the attribute table entry has information about 
the symbol. 

The dictionary is logically indexed by tue symbols. Hence, the 
symbol table acts as the index list of the dictionary. However, 
within the text of the module, the symoois are represented by 
symbol references. Symbol references are logical indices into 
the three parallel tables. Therefore, the syrnooi references are 
alternate indices for the dictionary. Tne symbol references 
correspond to the symbolic names used in the system architecture 
manual. 

Definition: A s ymbol refe rence is a logical index into the 

dictionary. when used, it selects the component 
corresponding to the symool it represents. It is valid only 
within tne module in which it was created. 

Definition: Tne tetraaic function insert symool causes a new 

symbol to be added to the symbol table or the designated 
dictionary and the corresponding entries in the linkage 
table and the attribute table to be filled in. The result 
of insert symbol (I;n;A;k) is the symool reference of a new 
entry in the dictionary k with tne value or I as the symbol 
entry, the value of L as cne linkage entry, and the value of 
A as the attribute entry. 

The msert_symbol function is much like tne normal insert 
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function. The major difrerence is taat two additional arguments, 
the linkage information and tae attribute information, are 
provided. Also, the result is not the cell name of the added 
cell, but is the symbol reference which will select the new 
entry. Using a special operator to add to tae dictionary makes 
it possible to discipline tae use of the dictionary. 

The attribute component is arbitrary and may be used to store 
information required by tae language being translated. Hence, it 
may serve as a compile-time dictionary and as a place to held 
initializing information at run time. The form of the linkage 
information will be discussed in Chapter 2.1. Basically, it 
consists of an indication as to whether the symbol is defined 
within the module or that it is defined in some other module. In 
the latter case, it contains the information on how to find the 
defining module. It also contains information on the storage 
class, since this affects linkage. 

Whenever the same symbol occurs iu two different modules, the 
occurrences may or may not be associated with tne same storage 
cell. One possible approach is to aefine the symbol-storage cell 
association to be the same for ail the modules in any collection 
of modules. Then, a different symbol would be needed for every 
distinct storage ceil to be referenced in the collection. This 
is annoying for one user and almost impossible to nanuie when two 
or more users are combining their programs. Therefore, it must 
be possible to define a context in which a particular 
symbol-storage cell association is to hold. It is then possible 
to have more than one association m a set of modules. 

Definition: A symbol is defi ned in a module if the storage cell 

associated with the symbol inside the module is different 
from tne storage cell associated with tne symbol in the 
surrounding context of tae module. The linxage information 
corresponding to the symbol m tne dictionary indicates when 
the symbol is defined. 

Definition: A local s ym b oi is a symbol waich is defined within 

the rnoduie iu which it occurs. 

The local symbols of SL correspond to the local symbols of APL 
and the declared internal symbols or PL/i. They are also known 
as bound symbols in mathematics. Local symbols are important 
because storage cells are allocated for local symbols when the 
module is used. All other symbols are gust references to storage 
cells allocated outside tae module. 

Definition: A symbol which is not local to a module is a free 

s ymbo l or a para m eter symbol. The linkage information for 
such symbols indicates how to find the definition of the 
symbol and the associated storage ceil. 
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The symbol-object association tor free symbols is derived from 
the surrounding context or the module. The method for 
determining this association ana tne surrounding context will be 
discussed in Chapter 2.3. Tne free symbols correspond to those 
symbols in PL/1 procedures and API functions which are not 
declared witnm the procedure or function. The resolution of 
parameter symbols is discussed a section 2.2.4. 

Definition; The text component or a module is a list of 

statements. Each statement is a list of symbol references. 

The list of symbol references represents an expression (see the 
next section) in Polish prefix form. Treating statements as a 
list makes it possible to select the statements oy a simple 
integer index. 'This maxes editing tne text much simpler. It 
also provides a clean definition of local labels. 

Definition: A local l abel, p ro to ty pe is a symbol defined in a 

module and associated with tne index of one of the 

statements in the text. 

The prototype is made into a local label by adding to the 
prototype information which indicates which generations of local 
storage were active when the label was created. 


2.2.3 3 ynta ctic Form of Pr og r am Text 


This section sets down tae constraints on the external syntax 
that are conceptually required, it is not to be interpreted as a 
specification of the syntax, but only of the form of the syntax. 
Many concrete syntaxes or external representations are compatible 
with tnese properties; one such representation is tne external 
form presented in Chapter 4.3. The external syntax is designed 
to be suitable for human use. It rs intended that an incremental 
translator will build the program representations described in 
the previous section. where rt rs relevant, the machine form 
will be discussed with the syntactic constraints. 


2.2.3.1 Symbol Lists 

Definition; Program text is a string of symbols. 

This is an important difference between AFS and existing systems. 
Unlike the bit encodings or System/370, bit encodings in AFS and 
physical addresses of hardware devices are xnown only to the 
implementation. Bit encodings are never displayed to programmers 
in hex dumps and can never be modified by them; instead, all 
communication is in the form of character strings deiinea in the 


IBM CONFIDENTIAL 





Chapter 2.2 


PROGRAM STRUCTURE AND INTERPRETATION 


63 


iogicai architecture. 

Definition: A s ymbo l consists of one or more characters treated 
as a single unit; tne implementation must include 

appropriate delimiters or character counts to indicate the 
extent of a symbol. 

Intuitively, symbols correspond to the toxens of PL/I and APL. 
They include denotations for constant, single ana multiple 
character operators, ana identifiers. There will be rules for 
determining the extent of symbols so that the last character of a 
symbol is obvious to a symbol parser (lexical analyzer). 

There are two classes of symbols: operator symbols that 

represent operators requiring operands to be evaluated, and 
elementary symbols that represent objects that ao not reguire 
operands to be evaluateu. These classes are distinguished so 
that it is possible to syntactically preprocess the text: 
Operators must be syntactically distinguished from elementary 
symbols if syntax cuecxing or parsing is to be done. In APL, 
variables are syntactically indistinguisnabie from user-defined 
operators; therefore, tne only way to tell if a symbol is an 
operator or a variable is to rind out what tne symbol represents 
at execute time. 

Definition: An elem e ntary symbol is a symbol without any 

syntactically-associated operands. Two subclasses are 
distinguished: The first subclass, literal symbols, 

consists of symbols waose rorm identifies the objects they 
represent; the second subclass, rep resentat i ve s ymboIs . 
consists of all the remaining elementary symbols. 


These two subclasses correspond to tne classes or constants and 
identifiers respectively. Examples of literal symbols are • XY2, 
3.4, 2+41, Examples of representative symbols are X, 
VAHIAaLE_QNE. The rules tor resolving representative symbols are 
given in Chapter 2.3. however, literal symbols can be resolved 
at translate time to a special constant table which is an 
extension of the aictionary. Each literal can be replaced by a 
special internal symbol reference to this table. 

Definition: An operator sym b ol is a symbol which has operands 
that are syntactically associated. 


There are at least two ways to distinguish operator and 
elementary symbols. One way is to enclose the arguments of an 
operator symbol in parentheses as is done with PL//I iunction 
references. The second way is to put a description of the number 
and location of the operands berore or after the operator in the 
piogram text. 

These definitions cause niladic functions to be considered to be 
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elementary symbols because they have no operands. However, there 
is no need to parse variables and mladic runctions in a 
different way. 


Definition: A simp le expres sion is either a single elementary 
symbol or an operator symbol, together with the correct 
number of operands. Each o pera nd is a simple expression. 


This defines expressions recursively beginning with elementary 
expressions such as constants, variables, and niiadic functions. 
These may be used as operands rot operator symbols to build one 
level expressions. Then, two level expressions may be built from 
these one level expressions or simple expressions. This allows 
arbitrarily deep nesting of operators. 


Definition: when an expression has the form of an operator 

together with a set of operands, the operator is called to 

top o pera tor. 

This definition reflects tue fact tnat the syntax of an 

expression is really a linear representation of a tree. The 
non-terminal nodes or this tree are the operators, the terminal 
nodes are the elementary symbols. Tne branches in the tree 

correspond to the operands or the operator to which they are 
attached. 


2.2. 3.2 Special Operators 

There are cases where it is necessary to use an operator symbol 
as an operand of another operator. One example of such a use 
occurs with the inner product operator in APL. It taxes two 
operators (e.g., ♦ and *) anu two arrays and produces a result. 

This is written A + . *B where *■ and * are not operators with 
operands, but are elementary symbols used with the dot operator. 
Because of the syntactic rules given above, it must be possible 
to syntactically distinguish tne two different uses or + and *. 

Definition: There is a prerix symbol quote wmch syntactically 

converts the occurrence of the symbol following it into an 
elementary occurrence. 

Bence, the APE inner product would be written in the strict 
syntax as inner (guate pius;guote xpn;A;B). in the extended 
syntax, a simpler expression similar to the APL ion might be 
adopted, but such a fora would he a syntactic macro whose 
expansion in strict syntax would nave to use elern. Mote that the 
APL form requires a precedence relation m conjunction with the 
dot operator to override the normal use of + and *. 

If quote is used witn elementary symbols, it uas no enect since 
it only indicates how to parse tne program ana not how the access 
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to a symbol is to be interpreted. This is covered below in 
discussing the evaluation of operands of operators. 

Another problem occurs wnen languages like APL are translated to 
SL. It is necessary to represent tne program text for APL in a 
partially parsed form. In those cases where it is impossible to 
tell syntactically now to parse tae symbol string, the delayed 
parse operator is used. 


definition: The dyadic d era ye d par se function 

operands. There are three legal combinations of 


taxes two 
operands: 


second operand 
monadic function 
dyadic function 
niiadic object 
illegal. The 


result of 


first operand 

1) niiadic object 

2) niiadic object 

3} partial dyauic fen 

Ail other combinations are 
delayea_parse in each case is: 

1) a niiadic object which is the result of applying the 
monadic function to tne niiadic object. 

2) a partial dyadic function which has as its first 
argument the niiadic object. Betore the dyadic 
function can be evaluated, the second argument must 
be obtained. 

3) a niiadic onject which is tne result of evaluating 
tne partial dyadic function with tne niiadic object 
as the second argument. 


This allows the APL text to be represented and the parsing to be 
completed at execute time. Tae APL expression A BCD E would 
oecome 

dpar (dpar (dpar ^dpar (E;D) ;C) ; B) ;A) 
where dpar stands for deiayed_parse. 


2.2.3.3 Grouping Expressions 

The simple expression is too restrictive a format for all 
programming. It is necessary to group expression which are 
executed only roc their side effects and not for the final 
result. These correspond to sets of fines in APL or a set of 
statements in PL/I. 

Definition: A grou p is a segment of program text beginning with 

an initial marker (e.g., left brace), continuing with 
expressions separated by a marker {e.g,, semicolon), called 
the statement marker, and ending with a final marker (e.g., 
right brace) . 

Definition: The initial and final' markers are called gr oup 

m arke rs. 

A group represents a "module constant". That is, tne translation 
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of a group yields a module. Hence, a group is very similar to a 
literal symbol. This tact maxes it reasonable to allow groups to 
occur where an elementary symbol can occur. This leads to 
syntactically embedding groups within groups. To accommodate 
this possibility, a group was defined over expressions rather 
than simple expressions. 

Definition: An expre s sion is either a simple expression or a 

group or an operator symbol, together with the correct 
number of operands. Each operand must be an expression. 

Definition: An expression which is one of the components of a 

group is called a statem ent. 

The syntactic rules given above allow a group to be syntactically 
embedded within an expression and, hence, within another group. 
Tnis is purely a syntactic convenience. Each group is translated 
to a separate module which does not contain the embedded groups. 
Instead, it contains interuaiiy-defined symools which are 
associated with the modules tor tne embedded groups. This 
process is analogous to tne nandlmg of literals. The procedure 
for resolving and connecting tne separate modules is discussed in 
Chapter 2.3. 

The following definitions are inserted to clarify which symbols 
are in the dictionary of a particular module. 

Definition: A symbol wmcn is pact of tne text enclosed by the 
group markers is con ta me d in the group defined by the 
markers. 


Definition: A symbol which is contained m a group A out is not 
only contained in groups textuaiiy contained in A is 
d irectly containe d in A. 


Only those symbols wmch are directly contained in a group are 
put m the dictionary for tne module generated by that group. 


A typical group is the set of statements wmch exchange the 
contents of two variables, A ana si. This requires a temporary 
location ana three statements; 


[stow (A;TEMP) ;stow (ii;A) ;stow (TEMP;b) } 


2.2.3.4 Declarations 


If all programming were done in the macnine fora ox SL, then 
declarations would unnecessary. Ail declarations could be done 
by executing the insert_symboi function on the appropriate module 
dictionary. However, it is necessary to have a way of indicating 
in the external syntactic form that certain symbols are being 
defined and that others are free or parameter symbols. 
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Therefore, the external syntax aiust have aeciarat ions. A 
declaration will be treated as a notation for one or more uses of 
insert_symbol on the dictionary or the module which results from 
translating the group in whxcn the declaration occurs. See 
Chapter 4.3 for the syntax oi declarations. 


2. 2. 3. 5 Functions 

One or the most powerful aspects or mathematical notation is the 
ability to abstract upon an existing expression to define a new 
function. An n-adic function can ue dennea from an expression 
ny designating u of the symbols occurring in that expression as 
being parameter symbols. When the new function is applied tc a 
set oi n values, these values are associated with the 
corresponding parameter symbols in the expression. The result of 
the function is the result of evaluating the expression in the 
context of these parameter symbol associations. 

It is important to note that the module produced by translating 
the group is a niiadic function. an evaluate request is reguired 
to cause an activation of the module to be created. The result of 
such an activation is the result of evaluating tha text of the 
module. Therefore, the group brackets act to delay the evaluation 
of the text in the group until an evaluate reguest is made. 
Hence, the group represents the text, not the evaluation of the 
text. It is, in fact, a module or niiadic function constant. 

Since a module already represents a function, it is relatively 
easy to create an n-adic inaction from it. All that is reguired 
is to modify the linkage inioraatiou of the symbols to be treated 
as parameter symbols. Inis can be done with rnsert_symbol. 
However, it is convenient to nave a syntactic form which clearly 
shows the functional abstraction. 

definition: The dyadic operator lamb da takes as its right 

operand a module and as its left operand an ordered list of 
symbols which are not local to that module. The result of 
the operation is a parameterized module. The symbols given 
in the left operand are marked as parameter sy aibol s. The 
parameter symbols will be resolved m tae order in which 
they occur in the iert operand of lambda. 

The parameter symbols must he resolved when a function is 
activated (see section 2.2.4) since the arguments may dirfer from 
use to use. However, the remaining symbols may have been 
previously resolved. For the rest of this chapter, it is assumed 
that aii symbols other than the parameter symbols nave already 
been resolved by an unspecified algorithm. This restriction is 
removed in Chapter 2.3. 

A good example of the use of the lambda operator is to define a 
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function which doubles its argument. Let X be a local variable. 
The expression 2<*X yields a value which is twice the value of X. 
This can be made into a function by maxing X a parameter symbol. 
The expression 

lambda (X; ^product (2;i)} ) 

yields a function which gives twice its argument whenever it is 
applied. It is assumed that the symbol 'product* is externally 
defined to be the multiply operator. The literal symbol *2* 
represents the object 2. Although the only local symbol in this 
function is a parameter symbol, rt is possible to have other 
local symbols as well as free symbols rn a function module. 


2.2.4 Activating a Fun ction 


A function rs used by maKing an evaluate reguest on rt. The 
evaluate reguest contains tne arguments to be used by the 
function. The function may or may not do the w.orX to compute the 
result itself. If the function rs to be reentrant, rt creates a 
new object with new local storage to compute the result. This 
allows the function to process otner reguests "simultaneously 1 *. 
If the function does not create a new object to compute the 
result, then the function automatrcaliy becomes serially reusable 
because of the reguest gueue rn tne storage ceil rt resides in. 
See Chapter 5.4 for further details on function activation. 


Definition: An evalu ate req u es t on a SL function performs the 

following actions: 

1) A new activation of tne function being called is 
created by the object receiving the evaluate 
re guest. 

2) The argument irst is passed to this new object via a 

start reguest. The start reguest causes the 

interpreter lor tne new activation to begin. 

3) The interpreter first associates tae parameter 
symbois in tne new activation witn the storage cells 
of the arguments rn the argument list. 

4) The text of the function is tnen interpreted. 


Definition: Eacn evaluate request creates an activat io n 

function which rs being interpreted. 


of the 


The matchiny of arguments to parameter symbols is left to the 
interpreter in the access machine as is the interpretation of the 
body of the operator object. Tars allows flexibility rn the 
definition of the evaluation of tne operator. The operator may 
be a SL function, as defined above. However, it may also be a 
primitive operator or a procedure rn some other programming 
language. For primitive operators, the system will access the 
argument list and the result of the operation is defined 
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axiomatically. Xu the case of procedures written m other 
languages, the access machine contains the interpreter tor these 
procedures. 


2.2.0 E xpre ss ion Inte r pretat ion 


Consider a single function being applied to a set ot numeric 
values. For example, the expression 2 + 3 indicates the 
application of the sum function to the operands, 2 and 3. The 
evaluation of this function is relatively simple. The values of 
its arguments are already computed. Therefore, to evaluate the 
function, it suffices to associate the arguments, 2 and 3, with 
the appropriate parameter symbols in tne code for tne sum 
function and to begin interpreting that code. 

This small example already snows several aspects of the 
interpretation process. if we assume that the sum function is 
not primitive, for example, it migat be defined in terms of 
operations using the Peano axioms for arithmetic. Then, we see 
that evaluating an operator may cause additional expressions to 
be interpreted. There are three steps in tne interpretation of 
the sum operator in the above example. First, the two operands 
are collected into a list of operands. Then, the function 
representing the operator is activated. The activation of the 
function causes the parameter symbols to be associated with the 
storage cells holding tne operands. Finally, tne expression 
which forms tae oody of tne function ror sum is interpreted. The 
result of the operation is tne value computed ny the 
interpretation of the body. 

In the example above, the operands were elementary symbols. The 
syntax allows the operands to oe expressions. In this case, the 
arguments are not the expressions themselves but are the values 
represented by those expressions. That is, tne function is 
applied to an argument list which is constructed from the results 
of evaluating tne expressions. Tin s complicates the 

interpretation of a function. Tae argument fist cannot be 
constructed until each of tae expressions forming the set of 
operands is evaluated. For example, in the expression, 
sum(2;times (3; 5)), the subexpression times (3;5) must be 
evaluated before the sum function can be evaiuateu. 

Definition: The occurrence of a literal symbol in the program 

text is replaced by an association to a read only storage 
cell which aolds a copy of the object the literal 

represents. Evaluation of a literal symbol yields the ceil 
name tor that cell. 

Literal symbols are treated as expressions to be evaluated at 
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"compile time". This is in fact what as done in most programming 
languages. A good example or this is the handling of vector 
constants in APL. 

Definition: The evaluation of an elementary symbol results in 

the cell name of the storage cell associated with that 
symbol. 

Since symbols are always associated with storage ceils, this is 
the most general resuit which could be computed. It is clear 
that the contents of a storage ceil can be obtained if the 
internal identifier for that caii is known. however, it is not 
possioie to determine tue ceil name of the ceii which held an 
object when only the object itse ii is Known. 

One problem with having the call name be the result or evaluating 
an elementary symbol is that it is often the contents of the cell 
or even the result of evaluating tae contents 01 the cell which 
is desired. Therefore, operators are provided in 3L to force the 
further evaluation of tae contents of a cell by making calls on 
the object stored in the ceii. 

Definition: The inter pretat i on ox an expression which consists 

solely of an elementary symbol is tae evaluation of that 
symbol. 

An operator symbol cannot be evaluated without its arguments. 
Hence, it is necessary to simultaneously aetiae the 
interpretation of an expression and an operator symbol. The 
interpretation is begun at the top of the tree representing the 
expression. The main reason for this is that it allows a context 
to be provided for the evaluation of the operanus. This context 
can be used to perform aragaioug, as defined by P. Abrahms. It 
can also be used for the type of optimization used in tne Boulder 
PL/I compiler. 

Definition: The inte r pretat i on of an expression which consists 

of an operator, together with a set of operands, is done m 
stages. 

1) The object iu tae storage ceii associated with the 
operator syrnool is accessed with an identify call to 
obtain its sttnoutes. If it is a function or 
procedure and tne required number of arguments 
agrees with the number or operands given, then stage 
2 is begun. otherwise, an error exception is 
raised. 

2) Each expression m tne operand set is interpreted. 
The results are stored in a set of buffer cells 
associated with tne evaluation of the operator. 
When aii tne operands have been evaluated, the 
a rgum e nt l is t, a vector of storage cells containing 
copies of the results, is constructed and stage 3 is 
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begun. 

3) The operator rs evaruated using the argument list. 
The result of the expression is the result of the 
interpretation of the operator. 

The order of evaluation is defined to be left to rigat to be 
consistent with the actual rrnplementations of most programming 
languages and to maxe it possible tp predict the oraer m which 
side efrects will occur. it is not felt that any freedom for 
parallel evaluation can be efrectrveiy exploited at this level. 
The advantage of predictability seems to outweigh any improvement 
due to parallelism. 

The arguments are passed by reference. This is reguired to 
implement such primitive runctions as replace. Replace must have 
access to the storage ceil to be modified if it is to operate 
correctly. This is only possible if the ceil name is the 
argument to the function. Cali oy value can be implemented by 
having the called function copy the contents of the cells 
referenced in the argument list. Cali by name is slightly mete 
difficult, but can be implemented by passing reierences to 
niladic functions. Then, these runctions would be evaluated at 
each use of the call by name parameter symbol within the text oi 
the called function. 

Definition: The ev a luati on of an operator symbol and an argument 

list is performed by maxing an evaluate reguest on the 

object contained in the storage cell associated with the 
operator symbol. The argument list rs passed as the 

argument of the evaluate reguest. 

The definition of interpretation shows that beginning 
interpretation of an operator causes other operators to also be 
interpreted. in particular, each operand of an operator will be 
interpreted. when the operator has a function body, then that 
expression rs also interpreted. Thus, many operators may be in 
some stage of the evaluation process. 

Definition: The state oi evaluation of each operator symbol 

being evaluated is xept m a collective object called an 
evaluan d. This collective object Keeps track of the current 
action being performed ana tae partial results which have 
been completed. 

The evaiuand holds the results of evaluating the operands prior 
to constructing the argument list. An evaiuand serves much the 
same function as the dark Btaex Control Word used in the 
Burroughs architecture. however, it controls the building of the 
argument lis, as well as the call on tne operator. It is so 
named because it represents a part of the expression being 
evaluated. It can be used to provide status mrormation for 
debugging reguests. 
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because evaluation of expressions is strictly left to right, the 
evaluands for the set of operator symbols wuich have not yet 

completed the evaluation of their operands form a chain. This 

chain of evaluands corresponds to tue stack segments of tne 

Burroughs machines. This cfaaxn is anchored in the PSfi and ends 
with the evaluand for tne symbol neiag currently evaluated by the 
interpre te r. 

The evaluation of a function generates a new activation which has 
its own P5R. The interpretation of tais new activation may 

create additional evaluands attached to the new PS&. These are 
indirectly connected to the evaluands in the PSS of the 
activation making the evaluate reguest by the dependency graph. 
The reguest causes the ceguestor to become independent on the 
respondent. These links in the dependency graph fora a chain 
through a set of activations. 

Definition: A activat ion chain is a subgraph of the dependency 

graph. Each edge (X,Y) or the activation chain has the 

property that X is an activation which has maae an evaluate 
reguest which caused Y to necome the respondent to that 
re guest. 

The activation chain contains the history of function 
invocations. It can be used m conjunction with the evaluands it 
links to provide the status imormation when a process is 
suspended. The activation chain is also used to identify 
generations of activation oriented (automatic) storage. 


2.2.6 S equen ti al an d P arallel Execution 


A module has a list of statements wuich can be interpreted in two 
different ways. Tne default evaluation of a module causes 
statements to be interpreted m strict left to right sequential 
order. In the transition to the next statement, the previous 
statement result is destroyed. The result or the group is defined 
to be tne result of the last statement executed in tne group. 

An alternative is to use tne parallel function. This function 
evaluates the statements in an arbitrary order. This may mean 
actually in parallel if more than one processor is available or 
interleaved execution. The result m this case is a list made up 
of the results of each statement. 

Definition: The monadic function pa ra llel taxes as its argument 

a module and yields tne list formed by concatenating the 
results of interpreting each of tne statements in the 
module. The order wmcn the statements are mterperted is 
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undelined. 

When dealing With groups, two addrtxona components are needed to 
define the current point of interpretation. The cursor specifies 
which module is currently active. The statement index indicates 
which statement within that group is active. Since evaluation of 
tne parallel function causes several statements or groups may be 
simultaneously active, taere can ne multiple activation chains. 
These chains form the ac tivat i on t re e. 

The syntactic group marxers (traces) have tne function of 
stopping the normal evaluation algorithm. That is, they leave the 
group unevaluated. if, however, tne group occurs in a context 
where a "value” is needed, the group will be evaluated 
sequentially. Such a context cau be created by the evaluate 
function, or by other vaiue-oriented functions sucn as stow or 
sum. The delay function is usea to override a value context. 


2.2.7 The Apply F unct i on 


When expressions or groups can be the result or a function, it is 
not possible to use the implicit invocation mechanism. For 
example, it might be necessary to select one or two runctions to 
apply depending on a truly value (TV). This might be written as 

(It TV, then quote sin else quote cos) (.5)-)X 

m the extended syntax. This oecoues 

TV select {.quote cos; quote sin] apply list .5 stow X 

m the uasic syntax. The strict syntax for this expression is 

stow (apply (select (TV ; (quote cos jquote sm] ) ;iist (.5)) ;X) 

Therefore, an e plicit apply function is needed to associate a 
function with its operands. it there are no operands, apply 
reduces to an evaluate function. 

Definition: The dyadic function apply, maxes an evaluate call on 

its first argument with rts expression X(X). second argument 
as the argument list. Apply (X; ¥) will yield the same result 
as the expression X (i) . 
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2.2.8 Se l ect ive an d Re petit! ve Control 


A powerful, yet disciplined system, requires the abilities for 
control to flow to one of several alternatives and to provide for 
repeated execution of a group. The former facilities is provided 
by the s elec t function, which extracts statements from a group. 
The repetitive facility is provided by the repeat function which 
causes a group to be repeated until an iteration condition is 
satisfied. 

It is possible to terminate a group anywaera during the 
sequencing of the group. The exit function causes the current 
group to be terminated ana yields tae value of its argument as 
the result. When it occurs within a group that is being 
repeated, it causes tne termination of tne current repetition. 
When it occurs in tne predicate, it terminates further 
repetitions. 

There are times when it is desirable to conditionally exit from a 
group with a value. This capability is proviaea by the 
conditIona 1 function. It takes as operands a predicate and a 
group. If the predicate yields 0, then the group is not executea 
and the result or the expression is nil. If tne predicate yields 
1, the effect is tye same as executing an exit function with the 
group as its argument. 

Gotos are supported but only indirectly. Tne goto function 
causes a sequence exception. The standard system action is to 
reestablish the environment of the label which is the argument of 
goto. However, the user may field the exception and reject the 
goto if he desires. 
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This cuapter discusses ana presents the rules tor resolving 
symbols to storage cells xu the object base. Txie various times 
at which symbols may oe resolved are described. Trie method for 
providing a context tor tree symbols is presented. The structure 
of a procedure is completed. 


2.3.1 Phases or P ro gram Execu t io a 


The concept of code which is executed at well defined times m 
the life of an executing program is presented. These time 
periods are called ph ases . Phases define when instances of 
variables may be created. The phases are: 
translate 
load 

activate 

execute 

deactivate 

unload 


2.3.2 Local Sy moo l R esoiution 


at any point in time, each symbol is associated with a storage 
cell by a resolution aap. Eacn module may have many activations 
for every load. Because tne contexts of these activations may 
difxer, each activation must logically nave its own unigue 
resolution map. Each separate resolution map will be called an 
en vir o nmen t. 

Instead of redoing the whole resolution map, the part of it which 
remains constant is factored into a common mapping schema. This 
schema associates each iocax symbol with a phase identilier and 
an offset into the storage for that phase. The mapping of local 
symbols is completed by indicating which instance of each phase 
corresponds to the desired euviroment. The mapping of free 
symbols is discussed in the next section. When a resolution map 
is restricted to the local symbols it is called a lo cal 
environmen t. 

When each phase is executed, storage is reserved by creating a 
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collective object for tacit phase. Ail allocations within that 
phase become part of that collective object. Therefore, given 
the offset and the identification of the correct instance of the 
phase, the mapping is well determeined. 

The storage allocated during the loading pnase corresponds to 
PL/I STATIC storage. PL/I AUTOMATIC storage corresponds to the 
storage allocated by the activate phase. If the deactivate phase 
does not explicitly destroy the collective object owning the 
storage, it will remain. This permits coroutines ana passing 
functions up the activity chain. 


2.3.3 Contex t f o r Free Symbois 


Local symbois are resolved to instances or storage cells 
connected with seme phase of tae procedure in which they are 
defined. Free symbols are resolved to local symbois m some 
other module. This section defines tne method for determining 
which local occurrence is used. 

A simple resolution rule is to use the first occurrence of the 
symbol found by searching the local environments of the modules 
on the activity chain. This may give access to too many symbols, 
so the stop function can be used to hide a symbol from the 
search. A symbol is vi sible to the search if tne stop function 
was not applied to it in some module in which it is visible. 

This rule does not provide for unique local environments, 
however, so tne c onn ect function can oe useu to define a 
particular module in which to Degin tne search. if c onne ct is 
executed within an active moduie then the particular instance of 
storage to be used rs also defined. The environment of module 
"A", winch uses conn ec t to bind module u d” is called the 
predecesso r enviro nmen t or module '* d M . if a symbol is not found 
m the predecessor environment tnen its predecessor is cnecKed, 
etc. The search terminates wnen no predecessor exrsts. The set 
of predecessors form a chain called the environ me nt ch ai n. Since 
many activations can exist, tnese chains form a tree called the 
envi ro nmen t tree . Tnis is a tree defined on the ownership tree. 

When an appropriate local symbol occurrence is found, the 
resolution map is extended ny a process called l in king. A 
reference to tne storage ceil which is associated with the found 
symbol occurrence is placed m tne resolution map position which 
corresponds to the free symbol. 


2.3.4 Alternate rules tor Free iyguooi Res olu ti on 
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Tiie search rules given above must be extended to handle PL/i 
EXTERNAL scope. What is needed is a metnod tor specifying wh ere 
in the environment or activity chain the searcn is to begin and 
end. This storage for a module in wnrcn the tree symbol is to be 
may be defined in terms or relative back, references along either 
the activity chain or tne environment chain. It may also be 
provided by a reference to an existing local environment. 
Similar conditions could be used to terminate the search. 


2.3.5 Modifling. Attribu tes a na V aides 


Having established how symbols are resolved to 
it is necessary to indicate how tne contents 
are set. There are several functions lor this 


storage locations, 
or these locations 
purpose. 


The object contained in a location may be cnanyed using the 
r epl ace function. If only the owned resource component is to be 
modified then the stow function is used. Eacn object may have 
set up constraints on tne values it will allow as own resources, 
so conversions may be caused by tne stow operation. 


The create function is provided to allow tne user to build new 
objects, given a description or tne desired format and an 
existing object from wmch to obtain the components of the new 
object. The description may be a data description or it may be a 
user defined access procedure. If the existing object is 
incompatible with the description, a conversion is required to 
build the new object. 


2.3.6 Review of Progra m Data Structure 


Given the rules of chapters 2.2 ana 2.3, a program module becomes 
a complex object. It is a collection or text lists, each of 
which corresponds to a phase m the life of the program. There 
is also a table of all symbols directly contained in the module. 
These are partitioned into local, tree, and parameter categories 
with the restriction that parameter symbols occur only in the 
execute phase modules. Labels of statements are also in this 
symbol table, along with references to the phase m which the 
label occurs. 

Each module is basically an ordered structure, wnere some of the 
component statements may be uniudexed. Tne index set is the set 
of line labels or statement labels. The elements of the 
structure are ordered by line iabei values. This allows 
replacements and changes to be made easily. 

Multiple entry points are allowed. They are represented by 
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parameters to a common entry point. This entry establishes the 
argument-parameter symbol correspondences and then branches to 
the appropriate starting point in the execute module. 
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This chapter treats the pror 1 eais of exceptional conditions and 
explicit creation of processes. Loth synchronous interupts such 
as overflow, and asynchronous interrupts such as 1/0 are defined. 
The mechanisms for identifying and handling such interrupts are 
given. 


Processes (tasxs) may be explicitly created and their execution 


may be monitored and temporarily 
mechanisms that debugging will ue 
of the control tree is described 
may be obtained. 


suspended. It rs through these 
rmplemented. The data structure 
to show now status information 


2.4.1 Ex cep tions an a S ynchronou s Interrupts 


When a prxmrtrve function rs evaluated, conditions which are not 
built into the language interpreter may occur. These conditions 
are called e xceptio ns. They cause interrupts which are 
synchronous with the evaluation of the function. These 
interrupts are processed by creating a function call which rs 
stacked onto the activation chain including the function causing 
the exception. 


The function for which tae exception occured rs located in some 
module "A". The procedure to handle the exception rs found by 
one of three possible rules. Within eacn module it xs possible 
to define a set of procedures to be used when particular 
exceptions occur. The first rule xs to require tne exception 
handling procedure to be defined in module «&»». If it is not then 
the system action rs used instead. The second possible rule is to 
search back up the activation chain in which the module resides 
for a definition of the execptron handler. This rs what PL/I 
does. The third rule xs to searcn back up the environment chain 
for the exception handler. 


It must be possible to simulate the occurrence of any exception 
under program control to facilitate debugging. There is an 
sig nal function which causes the exception given as its operand. 
The exceptions will be values in the language so they be used as 
arguments to functions or combined into sets. 
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2.4.2 C haagina S equential Flow 


In cnapter 2.2 the interpretation or a sequential group proceeded 
m strict left to right order. Most ol the programming languages 
to be supported allowed transrers in the flow of control. 
Therefore a seq ue nce except ion is defined to stop the normal 
sequence or evaluation and to provide an argument which specifies 
where the evaluation is to continue. This allows the user to 
field this exception it aiscipimeu programs are desired. 

As a aid to the user there is a cell for each group which 
remembers the point from which the last sequence exception 
transfered control. This is an aid to debugging programs with 
gotos. 

The question of transfers of control outsiae a module is more 
complex. It is necessary to designate an environment to resume 
as weil as a statement to continue the execution at. This means 
that, in general, a label has two components. It has a statement 
index and an environment rerereuce. The environment reference 
has in it the information on which module to resume. 

In the above discussion there was no dependency on the 
environment to resume stin Doing active. This permits 
coroutines and tne environments of ruactions which were passed 
upwards to be "ceactivatea". 


2.4.3 Proces ses a nd Mo nitors 


The parallel function does not provide sufricently tiexible 
multipc^grautming facilities. The reason is that the number of 
processes to be created must oe Known vixen tne parallel function 
is executed. The create function is provided to give finer 
control over the creation or new processes. it causes a new 
process in the suspended state to be created ana attached as 
subordinate to some process in tne activation chain leading to 
the process executing create . Tne result of cr eate is a cell 
name for the new process. 

A suDordinate process may be activated by applying the start 
function to its ceil name. It may be stopped temporarily with 
the sus pend function. The process whicn starts a suspended 
process may continue to run in "parallel” with the started 
process. When a process has completed, it may terminate itself 
by the d estroy function. it may also be terminated externally by 
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destroy. 

If process ”A H knows the cell name for process M B" then process 
"A" is a controli ng proces s for process ** . A controlling 
process can monitor the actions or its subordinate processes. 
The moni tor function suspends tne process executing it and starts 
the process given as an operand. The otner operand is a set of 
events, called i nterc epts. wnicn can occur in the monitored 
process. When an intercept occurs, tne monitored process is 
suspended and the monitoring process is restarted. The result of 
m oni tor is the intercept designator tor the intercept which 
caused the switch. Breakpoints may be handled by monitoring the 
execution of the statements with tne breaxpoints on them. 


Monitoring may be undone with the ignore tunction. It 
monitoring process to be reactivated with a special 
that it is to ignore the process it was monitoring, 
of the ignore function is nil. 


causes the 
mdicat ion 
The result 


Once a process is suspended, it may be temporarily activated 
using the inject lunation. This function is used to execute an 
expression in the environment of cue suspended process. It is 
used to change that envirome at, investigate the values of 
variables, etc. 


There are cases where it is necessary for one process to be able 
to suspend a second process only at well defined points in the 
second process. For example, it is desirable that attention 
signals interrupt the rumay r unction on statement boundaries. 
This capability is provided oy the priority function which also 
can be used to give information to the resource manager. 


2.4.4 Async h ro n ous In t errupt s 


The above interrupts are aii synchronized with the execution of 
the procedures. There are other events such as I/O completion 
and attention signals which occur asynchronously with respect to 
the execution of the program text. These may also be handled by 
a monitoring process. however, m this case the event being 
monitored may nave already occured before the monitoring action 
is attempted. Tneretore, it is necessary to save the event 
information in case it will oe monitored. Setting up tne initial 
value of an event variable is a problem. 

There are two ways to treat multiple occurrences or a monitored 
event. These can occur easily in asynchronous events and in 
processes which have parallel activation chains. The monitor can 
be treated as a serially reusable resource and the occurrences 
beyond the first can be gueued. Alternatively, a new copy of tne 
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monitoring process can be made to aaadle each new mterupt. This 
allows a potentially infinite number or copies oi the monitor to 
be created. Currently restricting monitors to be serially 
reusable seems to be more reasonable. 


2.4.5 The Data Structure of Contr ol 


The activation tree is a data structure waich contains the status 
information that determines tne flow of control. Each activation 
in the activation tree contains a cursor (group 
identifier,statement index and expression orfset),the process id 
for the chain in wnich it resides, and tne user identifier. 
These may be accessed for debugging information like the APL SI 
vector and to do validity cnecxing on accesses to protected 
objects. A particular activation may be identified by selection 
operations on the activation tree. The orancnes are ordered by 
their order of creation so numeric indices may be used. It is 
unlikly that the information in the activation tree can be 
modified using the normal data structure operations because it 
would undermine the system discipline. 


■f 

V. 
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2.5.1 2 u un itary of the 2 roolem a 


la aa ideal system, all data would be accurate, aad ao error 
could be generated anywhere within the system. In the real 
world, errors occur due to program mugs or uaruware bugs. Even 
if perfection could be acnieveu, it wouldn't necessarily be 
marketable since such a system would probably cost too much to 
produce and run too slowly to be salable. In designing a system, 
it is vital to specify the tecanigues to be used in handling the 
various type or errors that can occur. 

One way to contain the effect of an error is to partition the 
system into a set or levels sucn that an error at one level 
cannot propagate to the next higher level in tae system. The 
most obvious such partitioning is that between user data and 
system data. Ihe following discusses error handling in each of 
these two categories. 

User data can be put into two general categories, private data 
and public data. A job wnose data is ail private and which 
suffers an unrecoverable error may simply be re-run. It the job 
is run freguently and it errors are common and if rt is 
uneconomic to re-run the job in its entirety, then the gob should 
be temporally segmented. That is, the job should be broken into 
distinct time segments, in case or an error during one segment, 
the gob is begun again at the enu of the previous segment. This 
is simply the ramiliar mechanism of checjtpoint-restart. 

A job tnat only uses public data has a different set of problems, 
of which the update-in-place problem is the most obvious. The 
update-in-place problem rs solved by defining a mechanism tor 
gaining exclusive control ox a portion of public data, but this 
solution opens the door to the problem of deadlocks, and it can 
also cause large guantities of data to be made unavailable to 
other users while under the exclusive control of one user. 
Furthermore, if an error occurs so that it is necessary to 
terminate a job that had exclusive control of an entire data set, 
it is not clear which, if any, portions of tae data set were left 
in an .invalid state. A technique that reduces the scope of data 
potentially affected by an error, as well as tending to reduce 
the occurrence of deadlock, rs to segment the data into smaller 
units such as records or fields. One mignt call this approach 
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error control via physical segmentation as contrasted to temporal 
segmentation. A job to oe pertormed on a public data set would 
be be broken into a number or small operations to be performed on 
all or selected segments of the data set. In case an error 
occurred, the segment being operated on at the time would be the 
only segment to contain a possible error. Thererore, the segment 

could be flagged and the circumstances regarding the error 

incident could be reported to the Data Base admrnrstrator who 
would see to it that whatever steps were necessary were taken to 
correct the error. 

Errors in system data are another matter. while it may be 

possible for errors to occur in the system data pertaining to 
individual users with no more regrettable effect than the 

termination of some sunset of the users on the system, it is not 
tolerable for any errors to occur in the information the system 
has about its own structure. for example, it is not permissible 
for a queue element to be incorrectly deleted from a queue or for 
the queue to become intertwined with another queue. Errors in 
this class of data can potentially go undetected for some 
considerable period of time, a period of time suiricient for them 
to propagate themselves throughout every noox and cranny of the 
system. Sucn an error can compound itself so that it is not 
possible to xnow wuat information in the system is valid and what 
is invalid. Some approaches to tne problem of guaranteeing the 
validity of system data, as well as of attempting to ensure but 
not to guarantee the validity or user data, are outlined in 
Section 2.5.4 on hesource Management. 

On batch systems, users were oriered m effect two separate sets 
of functions with which to implement a solution to a problem; 
those provided by the compiler at compile time and those provided 
by the control program at execution time. On interactive 
systems, users frequently intermix compilation and execution. 
And on systems like APL/3&G with excellent debugging facilities, 
the user may suspend execution at any time to change his programs 
and then resume execution. Such systems, which allow fluctuating 
resource requirements for each user, raise problems that cannot 
be met by the batch-oriented algorithms or 03/350. 

An individual writing a program can control the resources 
available to arm in sucn a fashion as to accomplish the assigned 
function. The writers of a control program, on the other hand, 
are faced with the fact tnat no one can predict ail the 
combinations of functions tnat can oe requested by every 
statistically aberrant group of users ru any given time period, 
where each function requested implies some resource usage that 
the user has neither knowledge or or control over. Since the 
user is not aware of the resources required to accomplish a 
function he has requested, he cannot assist the control program 
in anticipating resource usage, and so the control program must 
constantly be prepared to handle ail worst case situations. 
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Holt, in his receat thesis on deadlock, nas distinguished usable 
resources from consumable resources. Consumable resources refer, 
for ail practical purposes, to tne type of interaction between 
processes typified by the WAIT-POST logic of OS/360. Processes 
may interact through operations on consumable resources gust as 
they may interact througn operations on reusable resources, and 
therefore, both types of interactions can contrrbute to the 
occurrence of deadrocxs. Tuare rs an important difference, 
however. A user process may rnteract on a consumable resource 
with either a system process or another process within hrs cwn 
job. Hrs process would not interact on a consumable resource 
with another process in a drstract gob. Therefore, the user can 
nurt only hrmself through the invalid or badly trmed use of a 
consumable resource. The system also nas the choice of waiting 
on either a user process or a system process. The rormer case 
should be strictly outlawed, srnce rt jeopardizes system 
security. The latter case rs normal ana is to oe expected. The 
point to be noted is that dependencies netween system processes 
interacting on consumable resources are known at aesxyn time, ana 
therefore deadlock possibilities can be handled at design time. 
Consumable resources should not ne a deadlock consideration for 
system processes. 

The following diagram describes a situation noted by E. M. Smith, 
It illustrates a potential invalid timing interaction between two 
CPU's which no amount of locking will avoid. The example is 




( 

Figure 2.5. 1-1 

xaa couFibhfif tiai 





86 


BASIC CONCEPTS AND STRUCTURES 


specifically stated in terms of CPU’s. It illustrates tie sort 
of timing interaction tnat must Be considered m the design of 
any multiprocessing control program such as AFS. 

In diagram 2.5. 1-1, CPU i sets oit 2 to one and then tests bit 1, 
while CPU 2 sets bit 1 to one and then tests bit 2. Both bit 1 
and bit 2 are assumed to have oeeu initialized to zero. Bit 1 is 
physically close to CPU 1, while bit 2 is physically close to CPU 
2. If timing interactions are ignored, tnat is, if it is assumed 
that all operations are completed mstantaneousiy, then it is 
apparent that at least one and perhaps both of the two CPU's will 
emerge from tne test of bit i or nit 2 having found that the 
tested bit was set to one. It is possible though that each CPU 
could send a signal to change the value of one of the bits and 
then test the other bit nerore the signal setting the other bit 
to 1 had been received, so that the two CPU's could find the bits 
both set to zero. 


2.5.2 Cla sses or Reso u rces 


ihe most fundamental resources m the system are space and time: 
in the physical implementation, space means storage in the 
Storage Management Subsystem (SMS) as defined m the System 
Architecture Manual, and time means execution time on a Program 
Processing Unit (PPU). Since ail objects reside m storage 
cells, they ail reguire some space m tne SMS; ana since ail 
objects are processes, they air reguire some execution time on a 
PPU in order to respond to a reguest. By definition, the SMS 
manages ail internal storage, and the PPU's service the reguests 
on the gueues for various objects. 

On conventional systems, space ana time nave Bean managed by 
software control programs, witn tne exception of some space 
management by hardware on bartered machines iixe tne 870/1t>5; on 
AFS, such control functions will oe performed completely Beneath 

the level of SL programming. Because of tnis increase in 

naraware control functions, tae engineering design must solve a 
number of proBlems normally faced only by programmers: For 

example, if off-line storage is treated as a logical extension of 
SMS, then the data patn for reguesting the operator to mount 

tapes must be dedicated to the SMS; otherwise, a deadlocx might 
arise if the operator was using tne console for a non-SMS 
function that caused paging in the SMS tnat caused an overflow of 
on-line storage that reguired the mounting of a new tape that 
required a message to ue sent to tne console tnat was still busy 
with the original request. utaer possibilities for deadlock 
could arise if dispatching a PPU reguired space in SMS and 
allocating space in SMS reguired some processing by a PPU; even 
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if normal cases of deadlock were completely eliminated, problems 
might arise if stanaard protocols were relaxed when a hardware 
error occurred and recovery procedures maae tne SMS dependent on 
a PPU tor emergency measures. Ir treated systematically, these 
problems are solvable by a series of levels like those discussed 
in section 2.5.1: the SMS must be the most fundamental part of 

the system and can never be logically dependent on services by 
anything outside of rtseir. Logical dependencies can be 
eliminated even in emergencies by dedicating certain resources, 
such as a special log-out area in a PPU, tnat could allow a 

physical PPU to become a logical part of the SMS for a certain 

period of time. On small machines, such procedures couid be used 
to allow a single PPU to perform aii functions: gust as the same 
hardware on a 360/25 can behave alternately like a CPU, a 
channel, and a control unit, a single PPU could switch hats and 
act either as a logical SMS or as a logical PPU. 

For the remainder of this chapter, we shall assume tnat space and 
time are allocated by hardware: tne SMS provides a practically 
limitless amount of storage upon reguest, and the PPU *s are queue 
driven boxes of hardware tnat dispatch themselves to service the 
logical processes. These are big assumptions that imply a lot of 

engineering design to make possible ana even more to make 

practical. See the System Architecture Manual for more detail 
about tne hardware design ana various simulation studies. 

Some resources, suen as ports, correspond to physical devices 
that have an independent existence. Other classes of resources 
are constructed by subaiiocating space and time: tne access 
machines of objects require time on a PPU to respond to requests; 
data representations, internal identifiers, procedural 
descriptions, and PSA's take up storage space in the SMS. 

Definition: Every object is a resource that belongs to one of 

the following classes: 

1) Finite: there is a limited number of objects with 

an equivalent status and ability to respond to 

requests. 

2) Unique: there is only one object with a particular 
status and ability to respond to requests. 

3} D a b oun ded: the object belongs to a potentially 
infinite class of equivalent objects; upon demand, a 
new object of the class can be created by 

suballocating space and time if available. 

Finite objects are ones like printers, where the total number is 
fixed, but any one or several may be equally capable of 

satisfying a request. Almost aii data objects are unique; copies 
of read-only objects may be acceptable in some cases, but tables 
and records like airline reservation or payroll files must have a 
single updatable copy. Unbounded resources correspond to 
function activations where a new one may be created for every 


IBM CONFIDENTIAL 



88 


BASIC CONCEPTS AND STKUCTUBES 


call upon the function. 

One way to increase the apparent number of finite resources is to 
create function activations that have the same logical properties 
as the limited resource. For example, a multiprogramming system 
with only one printer can provide many logical printers by 
creating multiple activations of a spooling program: each 
activation may respond to reguests exactly like a printer; at ter 
receiving a complete document, the activation will compete with 
other activations tor service on tne physical printer. 


2.b.3 Subsystems 


A hierarchical structure for a system is essential to a good 
design; Each level of the system can be designed and debugged 
independently. Errors arising in one level cannot propagate to 
higher levels. And the growth in tae total number of possible 
interactions between objects is linearly proportional to the 
number of objects, not exponential as in an unstructured design. 

The AF3 concept of subsystem is tne basis for operating systems, 
user jobs, and networks of systems. A subsystem rs a subset of a 
system in which all interactions with objects outside of the 
subsystem are channeled tnrouga a single resource manager. From 
the outside, a subsystem behaves like a single object; from the 
inside, the rest of the system is oaiy visible through the top. 

Definition: A subsystem is a sunset of tne object base with the 

following properties: 

1} There is a single onject called tne sub sy stem r oot 
from whica ail other objects in the subsystem are 
directly accessible (x.e. the subsystem forms a 
subtree or the ownership tree with the subsystem 
root as its root) . 

2) The subsystem root has an element called the 
r esour ce manag er that rs a collective object whose 
elements are synonyms to ail external objects used 
by the subsystem. 

3) The subsystem also forms a subtree of the 
environment tree with the subsystem root as its 
root. 

4) No object inside the subsystem is dependent on any 
finite resource except the ones whose synonyms are 
held by tne resource manager. 
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2.5.4 R esourc e Mana ge meat m AF S 


Resource allocation in AF3 basically follows Habermann's 
algorithm (CACIS, July 19o9) extended to meet the needs of the AFS 
system environment. Hanermann*s algorithm requires that each 
user define at job initiate time the maximum usage of each 
resource required by nis job. This maximum usage is called the 
claims specimen by the job. during the running of the job, the 
user requests resources as neeued up to the limit o£ his claims. 
Upon receiving a request tor resources, the system tests to 
determine (1) whether or not tue resources are available, and (2) 
whether or not a sate sequence exists. If the resources are 
available and a safe sequence exists, then the request is granted 
immediately. If one or the other of the two conditions is not 
true, then the request is not granted until the two conditions 
have become true. If tne request exceeds tne claim, then the 
request is refused. 

Defrnition: A sequence of joes, dual, J082, ..., JQBN, is called 

a safe se quenc e provided that it every job in the next 
instant requested aii tne resources it claimed at initiate 
tune, then J0B1, using the resources it now holds plus those 
currently rree, can run to completion and so tree up the 
resources it now holds, and tnen J0B2 using the resources it 
now holds plus those currently free plus tnose held by J0B1 
can run to completion, and so then J0B3 .... 


it is unreasonable to require tne user at the terminal to specify 
at logon time ail tne resources that he might use m the coming 
session. In order to permit tne user to request resources which 
he has not claimed previously, Barry Goldstein has suggested an 
important modification to naoermann's algorithm. Goldstein's 
algorithm allows the user to request resources which he has not 
prevrousiy claimed. In response to a request for resources, the 
system, as in Baoermann's algorithm, tests to see whether or not 
the resources are available and whether or not a safe sequence 
exists. If both conditions are true, the resources are granted 
immediately. If either condition is false, then the user nas to 
wait unless maxing him wait would create a deadiocs. Tne result 
is that a batch user wno never exceeds his claims will never 
encounter a deadlock and tnerefore need never prepare for 
handling deadlocks. On the otner hand, a terminal user can 
dynamically request resources taut had not previously been 
claimed at the cost of occasionally having to program his way cut 
of the deadlock. 

There are conflicting demands made by tae two needs to avoid 
deadlocks in allocating resources and to allocate resources in a 
network. Avoiding deadlock requires that tnere exists a single 
centralized allocator with complete Knowledge of all the 
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processes in the system and air cue resources assigned, to those 
processes. Running a network, on the otaer hana, requires that 
each installation xa the network, enjoy a measure or independence 
from the other installations. if centralized resource allocation 
were to be performed in a network, then every request for 
resources would have to oe referred back to the single specific 
node m the network chat contained the resource allocator. Since 
this is unfeasible, a method must be found for allocating 
resources at each node in a manner that is as independent as 
possible from the resource allocation decisions made at other 
nodes. This form of resource allocation can oe accomplished 
providing that additional constraints are placed on the safe 
sequences maintained by the resource allocators in the network. 

Let the system be composed of a is joint sets of resources and tor- 
each set of resources define a resource allocator. Assume that 
the resource allocators are ail at the same level, anu on top of 
them define a tree structure ot resource allocator coordinators. 
The particular tree structure is arbitrary out is fixed ror any 
given network. 

Local jobs are ones tnat am y use resources in one of the 
disjoint sets of resources. Distributed jobs are ones that use 
resources from two or more of the sets of resources. A job can 
enter the system at any node. A local job is transmitted to the 
node at which it will execute (n it wasn't submitted at that 
node). A distributed job may enter the network at any node but 
will be passed up the tree or resource allocator coordinators and 
possibly back down some otaer branch of the tree until it arrives 
at tne lowest level resource allocator coordinator (or RAC) that 
has jurisdiction over ali the resources claimed by the 
distributed job. The job is then broken up into suociaims tagged 
with the following field: 

COUNTER . TIME.RACID 

which specifies the position m tne safe sequence relative to 
other distributed jobs that tne current incoming distributed job 
is to occupy, Generally the idea is that distributed jobs should 
be processed m FIFO order. The problem is to determine the 
meaning of FIFO in an environment in which time scales may not be 
synchronized. A simple time stamp does not suiiice, since 
different RAC's using different clocks couid stamp requests for 
different jobs to oe sent to the same safe sequence with tne same 
time. Consequently, JObl mignt precede JOBz on one safe 
sequence, while JGB2 preceded JODl on another safe sequence. To 
avoid this and other timing problems, the claims sent down to the 
resource allocators are tagged wita the value COUNTER.TIME.RACID. 
TIME is the value of the RAC's time stamp, RACID is the 
identification of the RAC sending the request down, and COUNTER 
is the value of a counter maintained oy tne highest level RAC and 
sent down to ail lower RAC's, inis counter value acts as an 
artificai but uniform time scale for ail RAC's m the system. 
Since all distributeu joos maintain the same relative ordering 
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with respect to eacu otner in aii saie sequences in the system, 
qo deadlocks occur in the network. 


doit has pointed out (CACM, January 1971) the possibility ol jobs 
becoming effectively blocked m a saie sequence. Such a 
situation could occur if a sequence of high priority jobs 
continually occupied so much core that a a low priority job never 
had its request for a large amount of core satisfied. 
Consequently, the low priority job wouid be blocked indefinitely 
and could not oe guaranteed to complete in any given time. To 
assure tnat every job will eventually complete, doit proposes 
that jobs in the safe sequence be tagged with a time value that 
indicates the length of time tuey nave been waiting in the gueue. 
Then construction of the safe sequence is biased to favor those 
jobs that have been waitrag longest. 

Shoshaar (CACM, November l9o9) uas described the problems of 
permitting simultaneous access to the elements or a list 
structure. While it is not clear that any of the specific 
approaches that he recommended, should be adopted, AES must 
provide solutions that are at least as efrective. 


The THE System 
contained a very 
deadlocks rn the 
levels. Level 0 
consisted of the 
nandler. Level J 


as described oy bijxstra (CACM, May 1969) 
attractive approach to tue problem of avoiding 
system. The system was structured into six 
consisted of a clock and dispatcher. Level 1 
paging controller. Level 2 was the message 
handled source-sms. input/output. Level 4 held 


the problem programs, and bevel b was the user 


One inviolate 


rule of the system was that no process at a lower level could 
wart tor a process at a arguei level, though processes at a 
higher levei could wait for a process at a rower level. 
Consequently, deadlocks were avoided partly through the 
enforcement of this simple rule. Some such structuring should be 
undertaken for AFS not only to prevent deadlocks, but also to 
reduce the level of complexity of the system to a more manageable 
degree, and thereby allow a more complete and accurate design to 


ae formulated. 
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2.6.0 la trod act ion 


The operators or SL are txie nasis of the system. The elaborate 
structure of dyadic objects aud operators to worx on them is 
intended to implement an attribute examining system. The 
operators are the lowest level active element which can be 
programed. In this respect tuey are like S/360 instructions. 
The detailed runction or an operator depends in part on the 
attributes of the operands at the moment of execution. in this 
respect they are Iixe APL functions. The operators are also 
responsive to the environment in which taey are executing as 
determined by explicit program declaration statements ana the 
activation chain. This aspect oi operators is the contribution 
Of SL. 


The operands of an SL operator are objects residing m the 
storage cells associated with the operand symbols in the 
expression containing the operator symbol. Tne operator symbol 
itself is associated with a storage ceil whicn contains the 
function object to be activated. This last relationship enables 
easy operator redefinition when necessary. The dyadic nature of 
the operands complicates tae definition of the operator at the 
object level as compared to that of a simple system. The purpose 
is to simplify the description at tne program level. In analogy, 
the description of floating point operations are more complicated 
than those of the corresponding rixed point operations; the 
existence of taese operations, however, simplifies program 
statement by eliminating the need for scaling. 

2.6.0.1 Arguments 

Part of the definition of a function is the specification of the 
number and type of its arguments. For monadic and dyadic 
functions written m infix notation, the arguments can be 
recognized by having their symbols appear next to that for the 
function. This technique is used oy APL to distinguish between 
monadic and dyadic functions. In tne prefix form of notation the 
function must contain sufficient information to specify the 
number of arguments. The spelled out forms of the functions, 
whicn are different for monadic ana dyadic forms, must, 
accordingly, be used in tne pcenx notation. Functions which 
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require more than two arguments will be described as monadic, 
with their operands taxing the shape of lists or three or more 
members. The symbols wnicn are assigned to runctioos may do 

double duty in the sense of being used tor both a monadic and 
dyadic function. These symbols can only be used for infix 
notation, where the distinction can be made syntactically. 

Not all functions have single cnaracter symbols assigned to them 
yet. In some cases in which tins has not been done we have 
indicated which pairs of one monadic and one dyadic function 
should share the same symbol. As a first principle one might try 
to define the monadic form to be related to the dyadic through 
some sort of default, le., having the monadic form equal the 

dyadic with some special value tor the mrssing argument. The 
trouble with this is that for most symmetric operators the 

natural special value makes the runction into a no-op. For 

example, monauic plus rs a standard no-op. To get maximum 

mileage out of the basically limited number of single characters 
the monadic function is not usually defined m terms of the 

dyadic for symmetric functions. an attempt to be reasonable is 
made, however, in many cases following the example or APL. 

In addition to the number of arguments which a function expects 
one must specify the type of argument. 

Definition: A function may place certain restrictions on the 

types of its arguments. Any argument meeting these 

restrictions is called p ri mi tive to the function. The 

action oi the function on an argument of such a type is 
determined entirely by t tie definition of the function and 
not by function distribution. 

For example, numbers are primitive to tne antnmetic operations. 
Zero and one are primitive to tne logical operations. A mere 
subtle example is select. Any object can be primitive as a left 
argument. Any indexed object is primitive on the right. If, 
however, the right argument or select has a restricted index set, 
say it is a list, then tae primitive objects on the left become 
restricted, respectively, to integers. 


2.6.0.2 Function Distribution 

It aas gradually been accepted in programing languages that 
distribution of functions over structures of operands should be 
automatic as in APL ratner than requiring explicit loops as in 
early FONT NAN. Since our structures are very general, cur 
definition of function distribution must be so too. 

Ne shall discuss function distribution for dyadic functions. The 
situation for monadic functions is, in tact, simpler and can be 
deduced from the dyadic case. Suppose that a function appears 
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between two objects neither of waxen xs primitive. The function 
exaaiuies the two objects to see it they are two coiiective 
objects with identical index sets. Ir not, an error has 
occurred. If the condition is satisfied, the function is applied 
iteratively to the elements of the structures producing an 
identically indexed collective object as the result. it any pair 
of objects is not a pair of primitives, the analysis is executed 
recursively. lx at any stage of the recursion one operand is 
primitive and the other not, the primitive operand is imbedded by 
replication in a collective object matching that or the other 
operand and the function is evaluated. 

Note tnat function distribution applies only over indexed 
structures, most usually, in practice, over lists and arrays. 
Objects of type closure not primitive to the function being 
distributed are not uncovered for distribution. Stopping 
distribution is one of tne functions of encapsulation. 

Enclosure can also be used, in conjunction with function 
definition, to modify, as well as simply to control distribution. 
Suppose, for example, that one wished to carry out rational 
arithmetic with proper tractions Kept as integer pairs. One 
would wish for a function, ratsum, which is sum ror integers 
and defines the arithmetic sum for rationais. One defines 
rational numbers as enclosed coiiective objects consisting of two 
integers and an identifying field. Objects of type closure are 
made primitive to ratsum. when a closure is encountered, the 
function itself analyses the object to decide want to do with it. 

Function distribution can also ce explicitly controlea by certain 
functionals, as discussed in 2.6.5. 


2.6.1 Progra m Structuring. Ope r at or s 

This section has some symbols which are not properly operators. 
That is, they are not encountered at execute time. However, they 
are included for completeness. The operators given here are used 
in constructing a tunable procedure from symbol strings. 


2.6.1. 1 Parsing operators 

These operators are used to maxe it possible to break /the text 
into units and to build a parse tree. 
quote (cf 2.2.3.2) 
d elayed parse (cf 2. 2. 3.2) 
braces (cf 2. 2. 3.3) 
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2.6.1.2 Scope nuilding Operators 

These operators allow the user to tiefine symbol occurrences as 
being local, parameters, or tree and to build the context in 
which the free symbols will be resolved, 
i nsert sym bol (cf 2.2.2) 
lambda (cf 2. 2.3.5) 
s to p (cf 2.3.3) 
connect (cf 2.3.3) 
load 


2.6.1.3 Unique Name Creation 

These operators allow the user to create unique names from 
existing names. For example, tney can be used to create local 
temporaries. These unique names are not normally printed when 
the symbol table is dumped. 
unique-name 


a 


2.6.2 Object C ompositi on 

( 

This section includes tne operators which are used to construct 
objects from the primitive ojects of the system. 


2.6.2.1 Descriptor Defining 

These operators are used to build up the components of an object 
description from the built in access mechanisms or attributes. 
The result of these operators is an access machine. 


2.6.2.2 Object Constructor 

The onject constructor cr e at e taxes as operands an access machine 
and an existing scalar or collective object and produces an 
object which is a copy of the existing object converted to be 
consistent with the given access machine. 


2.6.3 S truct u re and Ind ex Op e ra tors 



This section contains the operators which are used to build 
complex data structures. it includes such categories as storage 
management, index sets, structural combination, and explicit 
structure linking. 
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2.6.3.1 Index Set Operators 

These are the basic operators which maxe use of the indexing 
facility and alter and examine annex sets. 

selec t 

The dyadic operator sel ect taxes tor its second operand an 
indexed collective ooject ana tor its first operand an index 
object of its second operand. The result is the 
corresponding element or tae collective object. 

ilis t 

The monadic function m st takes an indexed collective 
object for its operand. The result is a list of the index 
set tor the collective object. Since the index sets for 
common objects may ne guite large, tais operator must be 
used with caution. 

Structures of arbitrary complexity may be built from collective 
objects since tneir elements may themselves ne collectives. 
Because of the generality there is no way m tue strict syntax to 
index into subobjects other than oy repeated use or the indexing 
operator. For example to refer to an element on a sublast of a 
sublrst of A one writes: 

4 sei (1 sal (2 sei A} ). 

ibasa 

Tne monadic function xnase taxes an array or list for its 
argument and returns its base list. This is a list 
structure of depth 2 or 1 respectively which describes 
the structure of the argument. 

shap e 

donadrc shape taxes an array or list as its argument and 
returns the shape of tae argument. This rs a list structure 
of depth 1 or 0. 

igenerator 

The monadic f unction rg e ne rato r taxes a scalar number for 
its argument. it returns a list whose shape is given by the 
argument and whose elements are its own index set. 

For details on the preceding iunctions, refer to the table in 
section 2.1.7. Mote that Shape is the rho operator of APL. For 
primitive arrays, igenerator snape yields ibase. 

Additional operators are: 
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name va lue 

The dyadic function na m e va lue taxes as its arguments a 
value and an object that is to be treated as the index for 
tnat value in any collective object in which the result of 
name_value occurs. it can ne used to pass Keyword arguments 
in an evaluate request. 


2.6.3.2 Storage Management 


These operators are 
collective objects by 
collection own by the 
i nser t 
delete 


used to aad ana delete components of 
inserting ana deleting storage ceils in the 
object. 


2.0.3.3 Staccural combination 


These operators are used to piece separate structures together to 
form a single structure. There are several operators because of 
the different ways tnat structures may be combined. The simplest 
structure is a list. There is an element of indirection in a 
list wnich must be carefully controied. For example, let 


and 


A = 


B = 

vie must distinguish 


(,a,o,c), 

(,a,e,£) . 

between the lists 


and 


c ~ ^, a , n, o, a , e ,1) 

D = {, A,b) . 


2e introduce four list constructing operators wnich enable us to 
construct C and D from a ana B, as well as to perform 
other operations. 

catenate 

Catenat e taxes two operands, each or wnich is a list. The 
result is a list comprising the elements of the two lists. 

augmen t 

A ugment is a dyadic operator. The left argument must be a 
list. The right argument is added to the list. 

li st 

List is a monadic operator. It accepts any object as its 
operand and forms a one element irst wrth tna argument as 
the element. 
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ravel 

The monadic operator ravel taxes as armament an indexable 
object It produces tne resuit 

ilist 0 sel y. 


Se now observe that the list C can be termed by A cat B. The 
list D is formed by list A augment B. it is possible that 
catenate may be redefined to perform limited type conversion so 
that vectors and lists can be combined. In particular# by using 
the 0-vector as a left argument for cat a vector can be created 
from its elements by first forming a list and then converting. 

Tne next two operators permit the formation of general arrays 
from lists and the reshaping of existing arrays. 

r esh a pe 

The dyadic operator res nape tales for its left argument a 
shape, i.e., one of the types of object m the shape row of 
the table in 2.1.7. The left argument is raveled and then 
inserted in odometer order into a structure described by the 
left argument. Tne right argument is truncated or 
replicated as necessary. 

This operator is the dyadic rao of API. The order of entry 
of elements into the structure is as m tnat language. «e refer 
to this order as the odometer order. 

rebase 

R ebas e is a dyadic function. Its left argument must be an 
index base list. Tne rigat argument is r av eled and inserted 
into the appropriate structure in odometer order. 


2.8.3.4 Operators for Composing and Decomposing Scalars 

These operators are used to build an object whicn is to be 
treated lixe a scalar from a set of components and to obtain the 
components of an existing scalar onject. 

e ncl ose 

The monadic operator en clo se creates a scalar object whose 
owned resource is tne operand. The resulting obgect is a 
scalar of type closure. An enclosed synonym is a metonym. 

dis cl o se 

The monadic function d is clo se taxes as argument a scalar of 
type closure. The result is the object which is the 
resource of its operand. 


2.6.3.5 Explicitly Liaxed Structuring 
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These operators are used to puiia structures oa components which 
are not owned by the structure but are only referenced by it. 
These references may be explicitly followed or they may be 
implicitly followed when that rererenciag component is selected, 
a ccess 
p oint 
ult imate 
s ynonym 


2.6.3.6 Implicitly Defined Data Structures 

These operators really define data structures out may be used 
when the data structure is not unite. They derme a rule which 
completely determines the value of each component when the 
operands of the operators are given. They act lrhe encodings of 
the data structure. This is similar to the implicit definiton of 
a set using a predicate tne elements or tne set must satisfy, 
igea 
ste p 

set notation 


2.6.4 Op er ators f or do dl iving ob jects 


This section aescnoes tne operators which are used to modify 
either the own-resource component of an oogect or the contents of 
a storage cell, 
stow 
r epla ce 
r emov e 


2.6.0 C ontr ol of Func ti on Distribution 


In addition to the e nclose aua disclose operators, which 

provide indirect control of tne distribution of functions over 
collective objects, a numner of functionals provide direct 

control. This explicit control is only provided for lists and 
arrays, since those are the only collective objects whose 
structure is explicitly defined. 

redu ct io n 

The monadic function Seduction taxes a list of three 

elements for its argument. Tne first is a dyadic function. 
If the second argument is an array the definition of 

reduction is as m API, with the third argument replacing 


Idtt CO HF IDEMTiAL 






100 


BASIC 


CONCBPXB A Hi) STMUCTUdES 


Part 2 


the APL subscript. It cae second argument rs a list the 
result is the same as tor a vector with the same entries. 
If the thrrd argument rs omitted tne default is as in APL. 

inner produc t 

This functional is defined as m APL for arrays. It the 

arguments are lists the result is the same as for the 
corresponding vectors. 

outer- prod uct 

This functional is defined as in APL for arrays. If the 

structures are lists, the result is not a matrix but a list 
of the expected elements in odometer order. 

One desirable feature or arrays is tne ability to treat them as 
scalars m one or more dimension so that they can distribute in 
those dimension as scalars do. This feature is provided in APL 
by treating 1-vectors as identical to scalars and similarly 
treating a length of one in any dimension. Tnis achieves cae 
desirable feature at the expense of another, viz. # maintaining 
the distinction between scalars and other arrays. We believe 
that this distinction is wortu maintaining ana tnat arrays must 
be of identical structure for function distribution to occur. To 
provide the flexible matching, wa introduce another Xmd of 
object. 

Definition: A p art i al arra y is Iixe an array except that one or 

more entries in its base list may be scalars, 

A partial array is indexed exactly life the corresponding array 

in which scalar entries rn its base list have been replaced by 

one element lists. The index set in scalar dimensions is the 
entry in the base list for tnat dimension. The function ibase 
applied to a partial array produces the list structure of mixed 
depth described above. The function shape applied to a partial 
array produces an error. 

The dyadic functional map occurs between a function and an 
argument which is a collective object. It forces the 

function to refuse to accept the object as a primitive and 

to distribute over its elements. 


2.6.6 Element and P at t ern dea rc drug 


Two operators are used to provrae the reverse operatroa to 

indexing, 
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in dex 

The dyadic function inaex taxes tor its lett operand an 
array or list. The right operand is any object. The result 
is the index oi the first occurrence of the object in the 
array or list if it exists 

It is desirable to be able to search for a sub-collection of 
objects. By this we mean searching for one array or list imbedded 
in another. For this imbedding to be defined a way oi combining 
arrays of index objects must be defined. In the typical case of 
primitive arrays, arithmetic plus, together with its distribution 
properties can be used. 

l oca te 

There are two cases or locate, depending on whether the 
operands are arrays or lists. 

a) Let A and 3 be arrays with 1 the index object array 

of S. Let the ranks of A and 3 be egual. Let ccmb 

be a function defined on the index objects of A and 3, 
Then A loc S is B, an index object of A, such that 

B comb I sel A <—> s 

b) Let A be a list and 3 a pseudo-list. For lists comb 
is arithmetic sum. In this case locate is defined so that 
the Coppola identity, 

A loc 3 ♦ ilist 3 sel A <-> 3, 

is satisfied. 


2.6.7 C omputation al Operators 


This section describes the operators for uumerrcaily orrented 
computation. They create a new object using tneir operands as 
input to a rule or combination. hence they always cause copying 
to occur. The operands of an operator are objects; the result, 
another object. The operands, to enable implementation of 
standard languages, must contain several kinds oi information in 
their descriptors. There must be the information necessary to 
interpret the string of bits or whatever is in the machine as a 
number. In addition there must be the information which the 
programer associates with the operand through his declaration 
statements. For our present purposes a number or value is a 
concept not indigenous to Sh m terras or which we describe the 
functions of the operators. We assume tnat a value is something 
understandable to a user so tnat defining operations in terms of 
values makes sense. We shall define tne value to be used in 


IBfi CONFIDLN XIAL 



102 


BASIC CONCEPTS ABB STRUCT Uu ES 


Part 2 


operations in terms of a tix.0.1 radix representation with, radix 
ten. We assume approximately tne goals of PL/I But not the 
achievement of any particular implementation. we assume that the 
user can designate range and precision or precision only (fixed 
point and floating point, respectively) of his stored operand. 
During expression evaluation the machine will Keep at least the 
declared precision and, usually, no more than N digits, where 
ii depends on the machine. Running expressions on a machine with 
larger N will not yield less accurate results. N is currently 
a machine dependent parameter. In the case of SL it will 
presumably be declarable as part of the program ambience. 


The storage operands are held to tne precision specified by the 
programer. During expression evaluation greater precision will 
generally be aeld in temporary storage ceils. This is analogous 
to tne extra guard byte oi precision held for floating point 
numbers during S/360 instructions. Except xor division the 
precision retained will be at least as great as that maintained 
by PL/I. 


A furtner complication to operator specification is language 
dependency. A classic example of this is the FORTRAN divide. 
If the variables being divided are integers, the FORTRAN result 
is the integer obtained by truncation of tne correct answer, 
regardiess of the result destination. 

a *• b (FORTRAN) <—> (xT) x floor ads T<—a D 

Naturally the scope of vanaoiiity in this area is huge. If 
every programer chose to define differently the results of all 
possible ordered pairs or input descriptors the language 
dependence is SL would be unmanageable. Our goal is to provide 
enough flexibility to provide a reasonable set of alteraatives 
for future growth. Special glitches for today's anomalies will be 
provided. It is hoped tnat taey will wither away. 


For tne nonce we will define the iogimetric operators over the 
range of fixed and floating decimal numbers with base 10. PL/I 
notation will be used to designate the current descriptors, i.e,, 
(p) or (p,g) denotes precision. We assume that numbers are 
kept in signed true form. We also assume tnat the program has 
given some specification or tne amaience of execution. This is 
usually derivable from the data description for the entire 
expression. 


When an operator executes it knows the following; 

the values of its operands, including tne location of 
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significant digits 

the declared or computed precision or its operands 

the value of "N", the maximum precision to be used in the 

present environment 

the precision required in tne present expression, uetermined 
from the controiing assignment 

the number, K, of operators in tne present expression 


The machine can use run-time vaiues to help with precision 
problems, since it runs interpretively. Tne value oi an operand 
may contain more digits tnau its specified precision. This 
happens typically after a divide operation. A reasonable value is 
specified for the precision or tne result. Additional digits up 
to the precision available may be Kept since they will increase 
the accuracy of the result, but their loss wnl not cause an 
exce ption. 


The “precision required" will derive rrom the declared 
precision of destination objects ror assignment operations. In 
general a number of digits appropriate to the final assignment in 
a statement will be kept. This assignment will sometimes be 
called the controiing assignment. 


2.6.7.1 Operators with Identical domain and Range 

These operators are assocrative and may be used where 
associativity is required to maxe good use of the operator. The 
reduction functional is an example where associativity is needed. 

2.6.7. 1.1 Numeric Operators 

The prrmitive arguments for the numeric operators are numbers in 
ail cases. 

pius an d min us 

The monadic functions plus and minus return the same 
value and significance and precision as the input, with the 
sign changed in the case of min us . 

sign um 

Signum returns a single digit with precision (1,0) and value 
1,0, or -1, according as tne input is positive, zero, or 
negative, respectively. 

re cip (-s-) 

Reciprocal returns a value equal to one divided by tne value 
of the input. The result precision is (p,q), wherein p is 
equal to the precision oi tne input, and q is chosen to 
place the first significant digit of the result value at the 
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left of the field, lu addition, if the operation is 
followed in the expression by multiplication or 

exponentiation, the value is Kept as a ratioual number if 

the absolute value of the denominator is 2bo or less. 
Further, if the division is not exact m the specified 

field, additional digits up to N are Kept, but not 

considered crucial; i.e., their truncation will not cause an 
exception. 

ceiling and floor 

if the precision of the input is (p,q) , with q > 0, ce il ing 
and floo r return tne appropriate integer with precision 
(p-q,0). If g < 0 a domain exception occurs. 

There are additional monadic operators, to wit; 
exp 
in 

There are the dyadic forms of taese operators; 
sum 

dif ferenc e 

p roduct 

quotient 

max 

min 

po w er 

l og 

The g uotien t function returns a single scalar result, the 
quotient of its arguments. Two additional dyadic operators are 
related to this one. Together they provide the functions 
provided by two ditierent definitions of the function which has 
been called "mod” in some languages. It seems desirable to get 
away from the name "mod" altogether to avoid further confusion. 
Tne names we have caosen are, unlike "mod", consistent with 
mathematical usage. 

quotie nt r emai nder 

The dyadic function guotient_remaiader returns a two element 
list. The first element is tne same value as that returned 
by the quotient function. The second element is the 
remainder. 

r esidue 

The dyadic function resi d ue is defined as m APL. 
m agnit ude 

The monadic function magn it ud e yields tne absolute value of 
its argument. 

2.6.7.1.2 Logical operators 
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These operators return domain errors unless the input values are 
within acceptable limits or 0 or +1, It tne restriction is 
met, the return is tne appropriate single digit number with value 
or 0. The result precision is (1,0). Note, for example, 
that -»-» may not be an identity operation. 
not (-.) 
and 
or 

nand 

nor 


2.6.7.2 Operators with non-uarlorm Domain and/or Range 

These operators are not associative at ail times. In some cases 
the range may be a subset or tne domain so when the domain is 
restricted to that subset the operator is associative. 

2.6.7.2.1 Range and Domain Differ 

These are primarily comparison operators but the elementary 
search operators are also included m this class. 

eg 

ne 

Equal and not-egual taxe numbers and strings as primitives, 
srfith string primitives their definitions are the and and 
or reductions, respectively, of tne result for ordinary 
lists. 

Additional operators are: 
le 
it 

It 

ge 

member 

2.6.7.2.2 Dyadic Operators with Heterogeneous Domains 

These are not exactly computational operators since they really 
build new structures from existing ones. However, they are 
grouped here because their inputs are computational, 
e xpan d 
com press 
oase-va l ue 
rep resent a tio n 
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2.6.8 Selectio n Operat o rs 


This section consists of tne operators which only define an 
access path to an ooject. They do not make a copy of the 
selected object nor do they modify that object, 
s elec t 
t ak e 
dro£ 
r otat e 
r everse 


2.6.9 Contro l Op erat or s 


This section descnoes tae operators tor directing the flow of 
control. It xs divided into two parts. The first part is 
concerned with a single control path. The second part has the 
operators for multiple control paths. 


2.6.9. 1 Sequential Control 

These operators are used to start control flowing through a 
program and to modify and control the sequencing of the text of 
that program. 

e valuat e (cl 2.1.4} 
a pply (cf 2.2.7) 
e xi t (cf 2.2.6) 
repeat (cf 2.2.6) 
g ot o (cf 2.2.6) 
delay (cf 2.2.6) 
c on ditio nal (cf 2.2.8) 
signal (cf 2.4. 1) 


2.6.9.2 Multiple Control 

These operators allow parallel execution of expressions and are 
used to create, control, and monitor independent processes. 
parallel (cf 2.2.6) 
create (cf 2.4.3) 
destroy (cf 2.4.3) 
s us pend (cf 2.4.3) 
start (cf 2.4.3) 
m oni tor (cf 2.4,3) 
i gnor e (cf 2.4.3) 
i njec t (cf 2.4.3) 
priority (cf 2.4,3) 


IBM COMliDBNflAi. 




Chapter 2.6 


fUhcnoj* set 


107 


2.6.10 R esourc e Coordination 


This section describes the operators used for input/output, 
information flow between processes and for the allocation of 
resources. These operators are a separate class because they 
interact heavily witn the arbitrator. 


2.6.10.1 information Flow 

These operators are used noth to syncnronize independent 
processes and to provide the means for information transfer 
between two processes. There functions are discussed in section 

3.4.2. 


send 

message 

wait 

message 

sen d 

answer 

wai t 

answer 

introduce 


2.6.10.2 Resource Allocation 

These operators are used to make preliminary claims and to 
acquire resources known to the context in which they are 
executed. They also are usea to release tne resources. See 

chapter 2.5. 
c la im 
free 
acquire 
release 


2.6.11 adit a nd Search 


This section introduces tne operators for editing and searching. 
The approach to be used is to encoue the transformation tor a 
finite state transducer which taxes as input tne encoding, and 
the string to edit or searcn and produces as the output the 
result. The machine must be at least a generalized FSK but even 
more power may be required. 


2.6.11.1 Dyadic Translate 
The form is 
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translate (m;k ) , 

where 

ib is a translate machine 

k rs the translate subject. 

The purpose or transl a te is to translate the elements or the 
translate subject into an output form, subject to the 
constraints, manipulations, and. transformations specified by the 
translate machine. The types or translations which can be 
specified range from the finite state operations of the 360 EDIT, 
2DMK, Tfi, and TET through Fortran FGHHAT and PL/1 PICTUEE 
processing to interpreting/compiliug programming languages and 
recognizing/transducing rormai languages. 

The tr ansl ate subj ect is a collective object which is generally 
of type list. The elements of the list are the objects (e.g. 
tokens, characters, symbols) upon waich the translate machine is 
to operate. 

The transla te m ach ine is a collective object wmch owns two 
objects: the initialization function and the translate table. The 
translate table is a collective ob joct of matrix extraction. Its 
index set is the cross product of the set of distinct elements I 
m tne input and a set of states S. The elements of the translate 
table are objects which respond to an execute request with a 
value of nil , under, or an element of S. Hence, these elements 
may be functions {generally triadic), lambda-expressions, groups, 
variables, or constants, whose evaluation may entail side-effects 
(such as modirying a push-down stack or adding to an output 
list). The initialization function is basically similar to an 
element of the translate table. In response to an execute 
request, it may perform some housekeeping (or pre-processing, 
such as stack initialization) duties as a side effect, and return 
a value which is that element of 3 (together with the first 
element of the translate subject) at which translation is to 
commence. 

Translate operates in the following manner: After initializing 
the output (o) to undef and the input marker (i) to <j (i.e., the 
zeroth position in the translate subject), the initialization 
function is called. The resulting initial state, along with the 
current input, determine an element of tne translate table to be 
executed. This, m turn, produces a new state as its value 
which, together with the next translate subject element, can 
again be used as an index into the translate table object. This 
procedure is applied iteratively until either 

a) the new state is nil 
or 

b) the new state is unde f 
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Case (a) occurring concurrently witn exhaustion of the translate 
subject signifies a successrui translation, in which case the 
output (o) is returned as tae value. any otaer termination 
condition indicates that an error has occurred, in which case an 
exception is raised and tae value to be returnee is a collective 
object consisting of the uncompleted output(o), the input 
Barker (l) , the state(s) at the time of the error, and the 
complete translate subject. 

The input marker and output may be manipulated r>y the elements of 
the translate table, thus providing extended finite state 
operations. By suitable specification, translate has ail the 
power of a (simulated) Turing machine. In addition, recursive 
calls on translate permit the simulation of tree-like automata 
and non-determimstic automata. 

In SL-like terms, the function could be written as 

(m,k) lambda 
(del new (i ,s, o) ; 
undef—>o; 

0—>i; 

apply (sel {1 ,m) ; (o,i,x) ) ->s; 
repeat (s*nilA (s* undef) ; 

(apply {sel ( 

(sel (i + 1 —>i; k) , s) ; 
sel (I, m) ) ; 

(o,i, k) ) ->s) ) ; 
sel (s*nii; (o; (o,i,s,k) j ) 

} 

where sel stands for the select function. As an example of 
translate, consider tne roiiowing 5L program segment: 


0—>n; 

(o,i,k)X(A}=>T£0;A J; 
repeat( n+1->n<10; 

{(o, i, k) X£o cat (*$',n)->o; 
te s t (o; i; x) ; 

Bj =>Tp u; A j; 

(o, i ,k)X (o cat list n—>0; 
test (o; i; x) ; 

B}=>T£n;Bjj) ; 

syn T |1; Bj =>T Jp; Bj ; 
nii=>T[ nil; B J; 

(o,i,k) X(sei (shape (k) -2=i; (;o cat iist ' . *->o)) ; 

sei(3 res (shape (x)-a- i) =0 ; o cat list *, 1 —>o j) ) =>test 
translate ( (A, T) ;*00 10 2 34567B')~>res ult; 
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where sel is the select function, res is the dyadic residue 
function, and cat is the catenate function. 

The value of result would he the object 
$1,023,456.78 


2.6.11.2 Monadic Translate 


The monadic form of translate 


transla te (k.) 

takes as argument only the translate subject <u It is assumed 
that k. is a SL string in external syntax form. The result of 
translate is the internal, lunctioaai SL eguivaient of the 
external syntax. 
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SYSTEM CONCEPTS AND FACILITIES 


Part 2 described the Fundamental structures at tne basis of AFS. 
These structures provide tne equivalent of a "bare machine" that 
executes SL directly. This part describes system facilities 
built on top or that basis to provide a rich set of user oriented 
functions. 

An important concept or AFS is that there are no privileged 
instructions, only privileged resources. Since all operations 
available to tne operating system are therefore available to any 
user, special purpose systems as veil as IBii standard systems can 
be designed and run iiice ordinary jobs. 
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SYSTEM DESIGN CRITERIA 


The system design criteria are enumerated in terms o£ 
applications, operational environments, and service modes. These 
are derived from IS marxet requirements. The object tor the 
exercise is to classify the requirements into three somewhat 
Mutually independent categories. Criteria froa each category are 
used as the basis to Begin one aspect of the system design 
effort. 

Topics to be descrioed m tais section of the report give an 
indication oi the current effort to satisfy the application and 
certain of the operational environment criteria. 


3.1.1 A pplicati ons 


Criteria included in this category are focused on the types of 
user applications waich are prevalent during this time frame. 
Important applications include: 

* Data Entry/Data Retrieval, 

* Data Manipulation and Computation, and 

* Data Communications. 


3.1.2 o perat ional Environments 

Operational Environments are concerned with the aspects of 
physical demands and constraints on a system relative to 
performing user applications. Examples are: 

• Reliability, Serviceability, Availability 

• Size oi data base 

• Humber of lines ana terminals 

• Geographical distribution of: 
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• Users 

• Terminals 

• Data Bases 

• System nodes (in a network) 

- Traffic raie/iessaga mix 

- Response Time 

- Security/Privacy 


3.1.3 S ervic e Modes 

Service modes are concerned wrtn tne manner m which system 
services are exercised by a user m order to satisfy his 
application reyuirements whan subjected to the appropriate 
operational environment constraints. Service Modes include: 

• Transaction based (Routine processing) , 

• Interaction based (Ron-routine processing) , 

• Event-triggered, 

• batch, and 

• Message Switching. 
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ENVIRONMENT MANAGEMENT 


The principal functions perrormed oy an operating system are to 
set up the environments requitea by procedures and to execute 
them within those environments. Current systems nave normally 
assumed a "standard" environment, rn which all user code is to 
operate. This environment rs usuaiiy different from that 
required by components or tne operating system itself. Software 
tools tor the user, especially compilers, are designed under the 
assumption that the generated code is to operate in the 
“standard" environment. Most tools, therefore, are unusable in 
other contexts, and the "stanaard" environment is often unsuited 
to more ambitious user subsystems. waen faced by non-standard 
circumstances, therefore, the user or systems programmer rs on 
his own and usuaiiy resorts to tne worst hinds of trickery — by 
necessity, not by cnoice. As rs well known, 03/36J is full of 
such ad hoc solutions. 

Since environment construction and management prrmitives are 
included directly in Si, either IBM or user systems may set up 
environments which are well suited to their needs. This implies 
a new outlook on software tools, which no longer are allowed 
assumptions about the environment rn which generated code is to 
operate. In addition, as seen rn hart 2, steps are now required 
to imbed a procedure within its operating context. Software 
subsystems and virtual systems toiiow as corollaries or this 
approach. The disciplines which insure integrity, privacy, and 
security pervade the system, including all subsystems. 

System control and the command language rs also embedded m SL: 
user commands would translate to expressions in SL. This view of 
control is similar to the approacn taken in the July 1970 draft 
of the CCL report. In CCL tne control functions were programed 
in CCL procedures. This approach gives the user more flexibility 
in defining work fiow than a static ianguage iike JCL. Nesting 
of control procedures is also allowed. Any IBM standerd command 
language will be provrdea as part of tne system support as well 
as the 3L control functions. 


3.2.1 Genera l Syste m E nviron m ents 


The root of the system ownership tree is the system resource 


/T 
( •' 
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manager, which nas the responsibility for resource control. One 
such resource is the subsystem landlord. 


3.2.1. 1 System Specification 

The s ubsyste m l andlord is a collective object that owns all the 
highest level operating (sub) systems initially accessible to the 
user; these include systems like DOS, CP, CMS, OS, and TSS, as 
well as user-defined operating systems and SL subsystems, insert 
reguests may be made on it to add new operating systems, or to 
delete existing ones; suitable access rights for this capability 
will be instailation-deriaabie and presumably secure. General 
users may not make modifications to dedicated operating systems 
owned by the subsystem landlord. 

Interaction among operating systems, such as with CP/CMS, may be 
achieved via accessors assigned by the subsystem landlord. 


3.2.1.2 Resource Control 

The resource manager is a collective object which controls the 
allocation of space, time, and external devices, and the sharing 
of library resources global to multiple operating systems. It 
may logically (i.e., via synonyms) group elementary resources 
(such as ports, storage devices, or libraries) into new generic 
collective objects called resource p ackage s, and permit access to 
them by other system objects via the accessor mechanism. In this 
manner, operating systems may be given control over specific 
groups of terminals, device classes, channels, libraries, etc. 
Additionally, judicious assignment of access rights may permit 
more detailed delineation of resource availability. 

For resources which are snared by or accessible to more than one 
operating system, the resource manager will monitor the accesses 
and guard against lockups and ueadiocks. 


3.2.1.3 Initial Interpreter 

All ports to the outside woriu are controlled by the resource 
manager. Some subsets or these ports may be combined within a 
resource package and accessors to that resource package given to 
a dedicated subsystem. Such ports are called ded ic ated p orts ; a 
user sighing on to one of those ports is immediately confronted 
by the subsystem to which it was dedicated (e.g., a port 
dedicated to TSS would require the user to enter the usual LOGON 
message) . No other kinds of jobs save those meaningful to the 
controlling operating system may be entered from that port. 

Free ports , on the other hand, are initially uuassiyned by the 
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system. These ports fail under tne control of the fa it ial 
in te rp rete r which is part of the resource manager. The initial 
interpreter responds to user commands entered via a free port, 
and creates the corresponding subsystem under the subsystem 
landlord; such subsystems may include, for example, user-tailored 
versions of OS and DOS, or SL subsystems. Initial resource 
claims for the new subsystem may also be honoreu by the initial 
interpreter before control is transferred. 


3.2.2 Operatinq Syste m Envir o nm en ts 


An op e rating s yste m is a subsystem whose access machine is a 
process called the c on t rol pr o gram and whose resource consists of 
a set of jobs and a collection of irbraries called tne sys tem 
inpu t. Operating systems may be eituer d edica ted (bound) or fr ee . 
Dedicated subsystems engoy a semi-permanent status wrthru the 
system; that is, the resource pacxages assigned to them (in 
particular, groups of ports) may ne allocated for extended 
periods and the subsystems themselves would typically be 
generated by the system operator or tne installation. These 
subsystems would include ISM-suppired operating systems such as 
OS with TSO. Free subsystems are created by user request and are 
hence transient; they normally wril be destroyed wneu tne user 
signs off. These subsystems will primarily comprise 
user-rnrtiated and -tailored OS and other local operating 
systems, as well as ail SL suosystems. 


3.2.2.1 Resource Control 

Each operating system may be given accessors to resource packages 
via the resource manager; this may occur at the time the 
operating system rs added to the subsystem landlord, or 
dynamically when the operatrng system is mvoxed. In the former 
case, this permits an operating system to be sole accessor of a 
set of ports or lines; tnese resources are thus dedicated to that 
operating system until either the operatrng system rs deleted or 
the resource manager, which still owns tne resources, rescinds 
accessibility. In the case or dynamic allocation, ports and 
lines are accessible to the operating system on a request basis. 
In either case, resources such as disxs, on-ime or virtual 
printers and card-readers, and system libraries in resource 
packages accessible to operating systems are not shared by other 
systems; hence, management of these resources becomes the 
responsibility oi the operating system control programs, via the 
subsys te m resource m anagers . 

A dedicated operating system may nave the only accessor (as 
assigned by the system resource manager) to its system input; the 
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libraries contained therein may be accessed ay other systems 
provided the subsystem resource manager of the dedicated 
operating system permits an accessor to be established. 


3.2.2.2 Subsystem Resource Manager 

Each subsystem contains its own resource manager to control the 
allocation of resources from tne resource package. Requests for 
additional resource allocation ueyond that in the resource 
package are made through tne subsystem managers, which 
communicate directly with the system resource manager. It is the 
responsibility ox the subsystem managers to monitor resource 
requests and perform local deaaioc*. prevention ana control. 

The capability in tne system or nesting subsystems entails the 
recursive application of subsystem resource management. Each 
subsystem may permit a subsystem nested within it accessors to 
part or all of its resource package (as would be the case when 
running a free user-optioned uS under a free user-optioned CP); 
in that event, the nested subsystem^ resource manager would 
control those resources directiy. However, the higner-level 
subsystem may elect to maintain control over the resources, in 
which case lower-level subsystem resource managers would have to 
route resource requests through it (such might be the case when 
cunning an incremental Pl/1 compiler under a SL subsystem). 


3,2.2.3 Control Program 

The control program contains tne routines necessary to service 
the system input. This includes inserting ana deleting jobs, 
scheduling, priority assigning, interrupt handling, managing 
elements of the resource package(s), providing for job 
initiation/termination, and performing system maintenance. In 
terms of current operating systems, the control program refers to 
the job, task, and data management in 03/360; tne tasK, data, and 
program management in TSS/360; ana the virtual machine management 
in CP/67. 


3.2.2.4 System Input 

The operating system resource consists or the jobs which it is 
running or queueing, together witn the appropriate libraries and 
other resources contained in tne resource package allocated by 
the resource manager. The libraries contain language processors, 
maintenance and accounting files, language-associated 
subroutines, aiid any other semantic information required to 
define a job context. The job contains control information 
required by the operating system, along with program text or 
modules; in the case of the 3L system, this information is ail 


16M CiMPlOEN TIAL 



118 


3ISTMI1 FACILITIES 


part of the program itself. Joa iateyrrty and security is 
provided via the allocation or time and space lay the resource 
manager upon reguest by tae operating system. 


3.2.3 Job Env ir onm ents 


A job in the SL sense is a subsystem owuea by the subsystem 
landlord. 


3.2.3.1 Jobs in the 3L Environment 

SL joos may be created by tae initial interpreter at the user's 
request from a free port, or they may be created dynamically by 
existing SL subsystems. In tae former case, a user entering the 
system through a free port informs the initial interpreter of his 
desire to run in SL mode. This initiates the creation of a SL 
subsystem by the initial interpreter via insert requests on the 
subsystem landlord. The resource package for tae subsystem 
contains, minimally, an accessor to the tree port plus accessors 
to any of the user's files; m requesting a SL subsystem, the 
user may specify additional resources to be aiiocated. Hence, 
the gob is logically created at sign-on time and, if no 
subsystems with autonomous control are created in the interim, 
logically destroyed with sign-off. 

Jobs may also be inrtiatea rrom within a SL subsystem by insert 
requests on the subsystem landlord. Tae resources of the created 
job must initially be a sunset of the resource package granted to 
the creator. If the two subsystems are then to run rn parallel, 
only one may have access to tue entry port, and resource control 
(for shared resources) must be arbitrated by the system resource 
manager. If they are to run nested, then either or both may 
retain access to tne port; nowever, resource requests by the 
nested job's subsystem resource manager must be reflected bacx to 
the higher-level gob. In both cases, mother-daughter jobs (as 
well as other autonomous Sr subsystems) may communicate via 
shared data files or message transmission. 

Each SL subsystem, once createu, is free to make use of the 
entire SL language raciiity; subtasks may be created for serial 
or parallel execution, elements or tne resource package utilized, 
etc. The SL user has tne most freedom m employing the system 
for his problem solution, bur does not have the capability of 
impugning the system's integrity or security. 


3.2.3.2 Jobs in Non-SL Environments 
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Jobs under the control or roraign operating systems Mill maintain 
the identities they would have as if they were running under 
those systems anu witnin those systems' host architectures. 


3.2.3.3 Resource Control 

a SL job may utilize any resource available m its subsystem’s 
resource package, or it may request the resource manager to 

create additional resources lor it through the subsystem resource 
manager. However, requests roc increased or modified resources 
by nonconversatlonal gobs (i.e., those without a port in their 
resource package) will result m message transmission to the 

monitoring subsystem (or cancellation or the gob it no 
aigher-level gob exists) if the request cannot be granted. 

Hence, SL libraries, workspaces, tiles, etc. tali directly under 
the control or the resource manager; this provides additional 
cheesing facilities for muitipiy-accessidle file usage, as an 
example. The user’s own libraries and workspaces may be made 
accessible to the subsystem either at the time the subsystem is 
created, or as the user requires tuem. 

Resources for gobs under foreign operating systems are assigned 
to tne operating systems m the manner previously stated (section 
3.2.2.1). Whereas the accessing mechanism may be similar to that 
above, users of other operating systems can view resource 

availability in the manner to which they have become accustomed. 


3.2.3.4 Example of System Configuration 

The rollowing illustration is a static, logical representation of 
a system with 6 ports: ports 1 ana 2 are dedicated to an OS/370 
subsystem running one background and two interactive jobs; ports 
3 and 4 are dedicated to a TS3 subsystem running two interactive 
jobs; port 5 was iree, but has been assigned by the initial 
interpreter (upon user siyn-on) to an SL subsystem; and port 6 
was free, but has been assigned to a CP subsystem, which has in 
turn initiated a private OS/3 7 j subsystem with access to the same 
port. In addition, there is an SL subsystem which is apparently 
running in the background after having been initiated by another 
SL subsystem no longer active: 
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3.3.3 INTROD UCT ION 


System Control is concerned with tnat set of aata structures, 
processes and control mechanisms required to support and control 
the work, flow operations in tue system on two levels: 

• Functional 


• Server configuration 

On the functional level. System control is concerned with the 
initiation, coordination and termination of system functions in 
response to external (e.g., on-line user) stimuli! in 

• Data Communications 

• Data Entry ana Data Retrieval 

• Data Computation and Manipulation 

On the server configuration level. System Control is concerned 
witn the control ana synchronisation of system worK flow ana the 
allocation/aealiocation of resources. 

Functionally speaking. System Control can oe further partitioned 
to consist of System ''Command Control and System Monitor Control. 
System Coamaud Control is concerned with the control and 
management of normal system operations involving system functions 
and resources in response to external (e.g.; User) stimuli!. 
System Command Control operates m line with system work flow. 
Oil the other hand. System Monitor Control is responsible for the 
monitoring, detecting and handling or exceptional conditions 
occurring in the system. System Monitor Control operates in 
parallel with both the system worx riow stream ana System Command 
Control. 

In the present report, emphasis is focusea entirely on System 
Command Control, while capabilities characterizing System Monitor 
Control will be enumeratea in a iater section (3.4 System 
Functional Management). 
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Concepts fundamental to System Command Control will be presented 
from the following perspectives; 

• The Faculty Concept. Mere the system is viewed 

from the eyes of the system itself. Tne various areas of 
functional responsibilities are identified and grouped into 
autonomous functional partitions -- Faculties. 

• The Work. Flow concept. Here the system is viewed 
from the point of view of a user demand as tne demand travels 
througn the system. During this system walk-tnrough, certain 
system functions are orougnt into focus as a matter of system 
overhead while others are invoked explicitly as a result of 
interpretation and execution oy tne system of the user’s demand. 

• Basic Control Structures and Mechanisms. Here the 
system is viewed also from the vantage point of the system 
itself. An extension or tne key concepts (Part 2 ) in Object 
Base, ownership tree, ana program structure resulted in the 
formulation of the oasic structures and mechanisms for System 
Control. 


3.3.1 A Func tional Sys tem Str ucture 


The functional system structure (Figure 3.3.1 — 1) is described in 
terms of its two major constituent components: 

• The five functional Faculties 

• The daeue mecnanism tor inter-Faculty rnteractioa 


3.3.1.1 Five Faculties 

A partitioning of the total system iunctions into functional 
partitions based on areas or responsioiiities resulted in. a 
five-Faculty system structure . A summary description 
highlighting the roles of each Faculty is given below: 

1. The Terminal Faculty 

A wide range of terminal capaoilities are 
provided in a modular fashion, wmch can oe configured by the 
user to provide him with a selective combination of terminal 
functions to meet his specific application, operational and 
service mode reguiremeats. 

2. The Data Communications Faculty zf 

3 
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The Data Commumcdtious faculty is concerned 
with the transportation of data into and out of the system. The 
Data Communications functions are: 

• Transmission dependent 

* Terminal dependent 


* Message dependent 


3. The monitor Control faculty 


Tnis Faculty is responsible for the detection 
and handling of exceptional conditions occurring in the system. 
Also, it is responsible for system support ana administrative 
support type of operations. 


4. The Command Control faculty 

This Faculty is the central uud of control for 
the system. It is responsible lor the initiation, coordination 
and termination of system services in response to user demands. 
Also, it is cognizant at ail times of system work flow actxvxties 
and system resource availability status. 

Through a number of tables which Command 
Control maintarns, it is cognizant of: 

• The global working contexts about a user, 

• The particular worKiag contexts about a 
user during a specific instance ot user/system interaction, 

• System work activity status 

• System resource status 

5. The Data Control Faculty 

The responsibilities of this raculty cover the 
management and control for all system resident data. Functions 
include: 


• The accommodation of multiple logical 

structures 

« Security controi ior private and shareable 

data 

• Exclusive controi for concurrent access of 

shared data 
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• Eistoricdi versions of data 
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3,3. 1.2 Queue Mechauism lor Inter-Faculty Interaction 

In response to an external stimulus at tne user/system interface 
(Figure 3.3.1-1), one or more of tne Faculties must collaborate 
to perform the necessary worn, Inter-Faculty interactions are 
accomplished via the system Bequest and Besponse queues. 

A unified message structure for interaction rs employed by all 
Faculties. Pertinent information to be exchanged is assembled 
into a standard messaye structure. This information consists of: 

• Identifications -- Beguester and Besponder lb's, 

• Interaction types — Bequest and Besponse types, and 

• Parameter data. 

Furthermore, on a conceptual level, once a Faculty is activated, 
it will perform the work as specified until a logical conclusion 
point is reached. 


3.3.2 Nork Flow 


Once a functional system structure is postulated, tne next step 
in bringing the role of System Control into focus is to 
scrutinize work flow activity through the system aaa identify 
which Faculties would come into piay at which points in tne work, 
flow process. This is accomplished by a tecnnigue known as 
functional threading. This tecnnigue involves the tracing of 
external (user) demands througii tne sequences of system Faculty 
initiations, coordinations, and terminations. The object is to 
develop functional sequences or interacting Faculties m response 
to specific user stimuli!. To be responsive to market 
requirements, the scenario tor user stiraulii must be developed 
based on user applications for the FS time frame. 


An order hierarchy is required to specify the meaningful 
levels of control that must be established m tne system. These 
levels of control should be denned on the Worn. Session, Job, and 
Faulty levels. System Control utilizes tnis control hierarchy to 
establish and maintain successive levels of context for control 
relative to the execution of a user wors demand. 


3.3.3 B asic C ontrol Structure and M echanism s 
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The Faculty ana Woi'Jt Flow perspectives address the roles or 
System Control from a gross point of vie* and present a picture 
of the system structure m terms of runctioual aggregates. This 
is an "Outside-in" approacn--in that tue system is described 
starting from the application level and ending up inwards at a 
functional partition level. 

An entirely different approach to describing the roles of System 
Control is an , 'inside-0 ut' 1 approach. here the emphasis is placed 
on a description of the structures auu mechanisms wnich are basic 
to System Control. 


3.3.3.1 A Multi-Server System environment 

From the point or view of System Control, work, is performed by a 
combination or active and passive system elements. An active 
element is a system server (e. g. , a program processing unit) that 
is capable of doing work. Tue passive element is the program 
module(s) which contains algorithm(s) indicating how the work is 
to be performed. This is an iterative definition in that a 
combination of active and passive elements may appear to be the 
active element to a second passive element,etc. 

The external program structure for all programs (either system 
supervisor or user application programs) follows the standard 
PL/I static nesting structure (Figure 3.3.3-1). The external 
program structure for tne system supervisory programs for the 
Faculty system structure concept (section 3.3.1.1) is shown in 
figure 3.3.3-2. Logically, tne supervisor control program can be 
thought of as a single procedure which m turn consists of five 
basic procedures. 

Similarly, the internal program structure also assumes a uniform 
structure. The properties of this structure are: 

1. Ail prog rams are re-entrant. 

2. One or more program modules make up a program. 

3. A program module consists of two components: 

• A program text component 

• A symbol dictionary component 


The active system elements wnicn are capable of doing work 
operate m a multi-processing environment. 

Important concepts for System Control in tnis area include: 
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1. Multiprocessing is the normal mode of system 

operation. 

2. Server pool concept-- System servers are organized 
into pools of resource by type. Ail server pools are 
interconnected to one another through an interaction 
network(Figure 3.8.3-4). 

3. The concept of rioatrng supervisor control— No 
master/slave relationship ensts among server elements in the 
server pool. The supervisory control program winch is executed 
hy every available server is considered to be the master. 

4. Ail server elements have identical processing 
capabilrties and are equally qualified of performing work (either 
supervisory control or user application work) . No server is 
vested with any special processing roles. 

5. A gueue-dnven system concept-- server's interface 
for work assignment is via work queues. Bequests for work are 
always enqueued onto the appropriate worx queues. 


/f -q 
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3.3.3.2 System Interactions 


System Interactions are required Between active elements to 
accomplish control and management o£ system r auctions and 
resources to be responsive to au external stimulus. System 
interactions taxe place due to: 


1) Problem Interaction: These relate to logical 
dependencies witnm a program. Synchronization 
between concurrently executing instruction streams 
is required. 


2) 'Supervisory interaction: The 

interaction is concerned mainly with 

ox server resources and with tne 30 b 
tuning the system. 

3) System Interaction: Active system elements 

interact with one another to verity the validity ot 
system control data, to dynamically reconfigure the 
system due to loan nalancing or malfunctions, etc. 

Of these interactions. System control’s involvement in the 
supervisory function of tasx assignment and - server element 
selection will be descriued m some detail to furnish seme 
insight into the problem. 


supervisory 
the allocation 
ot dynamically 


The control algorithm on tasx assignment and server element 
selection is based on tne concept tuat all system resources are 
executing the most important tasxs as determined by the 
environment. in the system (Figure 3.3.3-4), as a server 
completes executron of tne worx specified by a tasx {a unit of 
work specification),rt executes the task assignment algorithm of 
the supervisory program and dequeues a new task from an 
appropriate work queue. Thus, tasxs must be assigned to server 
elements so that work can be periormed, and server elements must 
be selected from a pool or server elements to taxe on the tasks. 
The role of interaction networx is to facilitate in this 
assignment and selection process in order that an optimum system 
operational environment is established and maintained. 


Tasks include both supervisory and user tasks. New tasks 
are generated due to new 30 b introductions, task splittings, or 
I/O interrupts. Ail tasxs are assigned priority numbers. 

Similarly, an “availability index 1 ’ is associated with each server 
element which is executing a tasx. The ’’availability index” is 

derived directly from the priority of the task which is being 

executed by the server element. Tne ’’availability index” is a 
measure used to determine the relative degree of a server 
element’s readiness to taxe on a new task. An idle server 

element has the lowest ”avaiiinrirty index” (i.e,;most ready to 
take on a new task). 
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ihen a new task is being introduced into the system, it is 
assigned a priority number ana is enqueued onto the appropriate 
work queue. An idle server element is selected to take on the 
task. In the event no idle server elements are available, an 
active server element must be selected to take on the task. To 
make the selection, a comparison is made Detween the priority of 
the ready task and the availability index of each and every 
active server element. Tuose with lower availability indices are 
all available. The one server element with the lowest 
availaoility luuex, however, is aeemed to be most eligible and 
will be selected to take on the task. The lower priority active 
task which was being executed prior to the selection will go into 
a dormant state and will be aaqueuea onto the work queue. Should 
there be more than one eiigiuie server element with identical 
availability indices (i.e.; ail ace executing tasks with equal 
priority numbers), a tie-breaking algorithm will have to be 
executed. 
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A description of the important concepts from some of the key 
system functional areas as presented in this chapter to give an 
indication of the airections being followed. 


3.4.1 Data Base Manag em ent 


Data Base management is cone erne a with the accessing of data by 
multiple terminal users from an on-line centralized data base. A 
terminal user's access to the data base may be foe the purpose 

of: 

• Bead-only data entry and retrieval,and 

• Bead/Write data entry and retrieval: 

* Data insertion 

* Data modification 

* Data deletion 

Accessing takes place in a concurrent and independent manner m 
either the transaction processing mode {routinized processing) or 
interaction mode (non-r out mi zed processing) . 

Data base functions to ua addressed for the APS logical 
architecture must be responsive to these types of user 
requirements. Accordingly, topics to be addressed in this 
section touch upon all of the roliowing; 

• Data Independence 

• On-line availability 

- Convenient data entry ana retrieval 

• Multiple user data structures 

• Symbolic data access 

• Authorization to private and shared data 

- Exclusive controi to concurrently shareable 

- Data Base recovery 

- Historical versions or data 
- Transaction audit trail 


data 
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3.4. 1.1 D ata Ease M an a gement : An overview 

A logical representation of tae major data base components 
and interfaces is given in Figure 3.4.1.1-1. User activities in 
data entry/ retrieval, data manipulation and data base 
maintenance are presented to tae system as application and system 
programs. The procedural specifications of the programs are 
defined independently of tae data descriptions. Functional 
capaoiiities in each area are made available to tne users via the 
Data Manipulation and the Data Description languages. Definition 
of multiple logical data structures on the same system resident 
data is allowed to accommodate the many views wnich independent 
users may elect to see data. Tne entity record set concept in 
terms of entity attribute description of external things is used 
as the vehicle for logical data structure representation. All 
data accesses are suogect to system data exclusive control which 
is responsible to act as a filtering function to resolve the 
contention problem due to concurrently shareable data reguests. 
Data base address space is a multi- linear symbolic address 
space. In addition, data recovery constitutes an integral part of 
the total data base management function. 
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3.4.1.2 Data Base La n guage C apabilit ies 

The Data Description Language (DDL) is the language used to 
define an Entity Record Set. An Entity is a person, place, or 
thing. The things may be real or abstract. An entity is that 
about which a user wishes to record intormation in tne aata base. 
An entity record set is a collection of similar entities (Figure 
3.4. 1.2-1). To completely describe an entity record set, it is 
necessary that; 

The attributes which describe the entity are described. 

The entity records maxing up the entity record set are 
described. 

The data names and tneir synouyms are described. 

In addition, tne DDL can ne used to describe the physical 
characteristics of data in the data base. However, these 
capabilities are available ouly to the system installation 
manager. 

The Data Manipulation Language (DHL) is the language which 
enables the user to manipulate the iogicai data m his 
application program. Data manipulation implies data entry and 
retrieval as well as computation and processing. Both of these 
capabilities will be supported in TSL as operators. Since a user 
may wish to converse using any of the five languages; PL/I, 
FORTRAN, COBOL, SPG, and APL, DHL must rely on a host language to 

provide the computational capabilities. DML ,in turn, will 

provide the language interlace between tne program and the data 
base. Therefore, all calls to ana from the data base to retrieve 

data, to enter data, to modify data, or to delete data are 

invoked via DML operators. 


3.4.1.3 The Entity Re cord Set 

An entity record set is a two. dimensional array 
representation of data structures in terms of Entities and 
Attributes (Figure3.4.1.2-1). An entity is a person, place, or 
thing. Attributes are the property classes which characterize an 
entity. An entity record set is a collection of similar 
entities. Also, associated with each entity record set is an 
attribute whose values have a one-to-one relationship with the 
entities (i.e. ; the unigue identifiers). Thus, an entity record 
is that collection of attribute values which describe an entity. 

Attributes for an employee entity record set are; 
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1. 

2 . 

3. 

4. 

5. 

6 . 

7. 

8 . 
9. 

10 . 

11 . 

12 . 

13. 


Unique Identifier 
Employee name 
Social security 
Sex 

Birtadate 
Data of dire 
Department assignment 
Division assignment 
Education record 
Marital status 
Position 

Pert. Evaluation 
Salary 


as of date 
as of date 
as of date 
as of date 


Attribute type 1 is me unique identifier attribute. 
AttriDUte types 2 througa 13 are facts about the employee entity. 
A fact is a relation - a correspondence Detween members from two 
sets. Attribute types 2 through 6 establish a one-to-one 
relationship between a meaner from the employee entity set and 
the respective attrioutes. For instance, there can be only one 
"date of hire” attribute value for an employee. On the other 
hand, however, attribute types 7 through 13 establish more 
complex relationships. ho one-to-one relationships exist. 
Furthermore, each of the relationships can be qualified by a time 
parameter. Thus, an employee can ae assigned to work in more 
than one department as of a certain date. 


The internal system organization of the data for an entity record 
set must be such that it is responsive to the many ways a user 
may elect to view the data. One way to express an entity record 
set is in terms of a collection of relation sets (Figure 
3.4.1.3-1). A relation set is an entity record set which has only 
a pair of attributes - - one of these being the identity 

attribute. Thus, 

data required for the employee entity record set can be 
materialized rrorn the twelve relation sets. Note that tne 
identity attribute has ueen replicated twelve times to provide 
the connectivity required to link toqether the pertinent relation 
sets. 
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3.4.1.4 Data Integri ty 


Data integrity is addressed based on the way system 
exercises exclusive control to resolve contention, modification 
and update problems due to independent concurrent data accesses 
on data from a centralized on-liue data base. Also, data 
integrity is concerned witn the way data recovery is handled to 
checkpoint pertinent data base information so that operations may 
be restarted in case of a catastropnic data oase failure. 


3.4*1.4.1 Exclusive Co ntrol 

Ail system resident data can ne classified as: 
Read Only Private 


Read/Nrite Snareable 


All possible ways in whicn a user may choose to access data 
on an entity record set are saowu'm Figure 3.4,1.4-1, However, 
when two or more independent users are maxing simultaneous data 
access requests on the same entity record set, exclusive control 
must oe exercised. Parameters whicn the system must consider in 
performing the exclusive control function are determined by the 
type of entity record set involved (i.e.; Read/Wnte or 
Eead-Only), and by the type of data access 
requests(i.e.;Read-only or R/N) . 
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3.4.1.4.2 Data Base R ecovery 

The second aspect of the aata integrity problem will be 
addressed by focusing attention to the functional organization of 
a specific mecnanism for data base recovery - - a Journal 
organization. System roles whicn can be ruitliieu by a Journal 
include: 

1. Data Base Recovery— Ari data access reguests which 

cause data modifications to taKe place will cause the 
modifications to be reflected m both the on-line data 
base and the Journal. 

2. Historical Versions or data -- Data in tne Journal is 
checkpointed periodically to give a snapshot in tiee 
of the data base content. 

3. Transaction audit trail—Ail data modificiations 
must be captured in tne Journal m the exact manner 
as the modifications are made. 


A Journal organization waich fulfills these basic principles 
is given in Figure 3.4. 1.4-2. There are two types of Journal 
Records: the Checkpoint Journal records (Journal Records 5 and 
41); and. Transaction Journal records (Journal Records 6, 14, 16, 

18, and 36). Also, there are three types of Journal threads: the 
Datum thread, the Transaction thread, and the Attribute 
Transaction thread. 

The Transaction Journal record is created in the Journal 
whenever a transaction taxes place. The Checkpoint Journal 
record, on the other hand, is a system assembled Journal record 
which reflects the status or data as of the time the record is 
created. 

The threads are the mechanism by which to connect together 
ali those Journal records which are generated within particular 
contex ts. 
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3.4.2 D at a Co mmunicat ions 


3,4.2.1 Background 

The data communications area, xn comparison to the other major 
functional areas of a aata processing system, is in an earlier 
stage of evolution. As a result special attention is required to 
architect a system structure that provides this area with the 
flexibility to properly evolve aurmy the product life of AFS 
without compromising tne other areas of the system and the 
overall system structure itselr. 

The basic tenets of AFS postulates, with yooa technical 
justification, the availability of Storage Management Units 
(SHUs) with the capability of providing viable random access to 
an essentially infinite logical addressing space opaque to the 
individual performance /capacity characteristics of the various 
storage devices in a SMU. They further postulates the 
availability of Program Processor Units (PPUs) with a functional 
capaoility of providing a high-level System Language (SL) 
interface, described in Part 2 in this document, and be opaque to 
the number and individual performance characteristics of the 
various program processors m a PPU. In some sense, these could 
be thought of as '•ultimate" interfaces to these units - or at 
least ones at a very advanced conceptual level. 

A compatible level is not anticipated for the data communications 
area at the time AFS is introductea, however, enough is known to 
allow an architectural structure to be developed which can be 
evolved with low impact to the system and negiibie impact to 
application programmers. 

What then are the characteristics of the data communications area 
that contrast its architectural status to that of the SMU and the 
PPU? 

An (operating) system essentially simultaneously services many 
users typically at a centralized facility. On the other hand, 
data communications must m general deal with hardware devices 
that interface with a set of individual users at distributed 
locations. The former allows for highly functional interface 
levels and short well- controlled internal IBfl data paths. The 
iatter typically necessitates low costs at the device and needs 
to append functions of a system m a time-sharing manner in order 
to provide the desired user interface. In addition the long 
data paths, generally external to IBM products (telephone lines, 
etc.), create significant additional problems in themselves. 

Since the advent of LSI will allow for expanded device function, 
the increase in the data communications market will bring about 
dramatic changes m the technology and pricing oi communication 
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paths, and the requirement will grow tor more application program 
independence or device characteristics, a system architectural 
framework must he established which is both flexible to such 
changes yet provides guidelines to allow them to properly evolve. 

Further complicating this area are the marxet regurrements to 
allow present systems and devices to co-exist rn an emulated 
{virtual) mode under AFS; to provide a means tor dynamic 
interchange with those systems (as weii as ones in separate 
installations) and devices; ana to allow for most hardware 
devices to transcend the introduction of AFS. Essential to 
achieving a smoother translation from noth an internal IBM 
programming and engineering viewpoint as well as an external 
customer viewpoint will ne an early common and coordinated 
recognition of FS goals, and tradeoffs within all present 
products during the interim toward tnose goafs. This is 
discussed in more detarl in chapter 3,5 


3.4.2.2 Basxc Concepts 

A set of basic concepts have seen rdentified xor establishing 
iong-range criteria tor data communication tradeoffs: 

- All physical I/O (external) to source-sink devices and 
other systems will be handled oy the communication unit (CU) 
of the installation. This includes unit record and sensor 
devices as well as typical communications terminals. 

- Logical I/O, i.e. as seen from au application program and 
most of the AFS control program, will have 
virtual/1ocai/remote transparency. This includes any dynamic 
interchange with other virtual systems. Physical I/O, i.e. 
as viewed from the Source/Srnk (S/S) sunsystem of the 
control program, will nave iocal/remote transparency. 

- The SL and hence dLL (digher-Level Languages) and other PP 
interfaces to application programs will ce ny means of a 
minimum set or device classes. The FDL (Field Descriptor 
Languages) for pre-formatrng data structures on complex 
devices such as graphics will both simplify application 
programs and increase their degree or device independence. 

- Both the terminal user and tne application programmer have 
functional interfaces - independent of their locations or 
path connecting them. The logic to accomplish these 
functions from either eua should look like it is satisfied 
either by the other or the terminal device in between them. 
By terminal here, is meant either a single terminal on a 
cluster or common terminals with a central controller 
(compound terminal). Cost tradeoffs have dictated, and are 
expected to continue to dictate, that improved 
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cost/perforaance can be achieved it some of this apparent 
terminal device logic is implemented in the AFS control 
program. This logic has two parts: one is the formating 

field descriptors mentioned earlier which mast be specified 
by the customer, and tne other is simply good 
hardware/sortware tradeorrs. it is important to keep these 
logically separate from the path functions required to 
connect the terminal with the system. These path functions 
are to be performed in the CU and the other network 
management units between the terminal and tne system. 

A general AFS control program queuing mechanism for 
passing work to be done between processes will allow 
resource management to tune tne system ror a range or 
response requirements. Tne interface to tne CU will be a 
consistent extension ol tuis queuing mechanism. 


3.4.2.3 Types 

Data communications with tne system neeu to be examined at the 
logical I/O interface and of tne pnysical I/O rnterface. Because 
of tne basic AFS concepts or distributed (network) data and 
programs as well as virtual devices and systems, there is 
generally not a i:i relationship between these two interlaces. 

At both interfaces, however, information is considered to be 
consu a iaabl e, i.e. once sent, it can not be obtained again, and 
once received, it cannot be requested agarn. 

3.4.2.3.1 Logical i/0 

Logical I/O is defined to be explicit operations mane by a 
program to communicate outside tne logical closed entity or 
environment containing its Known authorized data, programs, and 
system services. Such communications are called m essag es if they 
represent original information being sent or received and answers 
it they are requesting a response to a previously sent message. 

Inter-A FS_dobs - These messages provide for interchange 

between normally independent AFS environments that want to 
establish local communication pains. Full supporting system 
services will include dynamic establishment and validation 
of authority and ability ror controlled snaring or data and 
programs. 

S ource/S ink - These messages provide for interchange with 
areas outside AFS. These areas are either devices or other 
operating systems (networks). By means of a well structured 
data communications path, the 3L interlace to these areas 
will be made almost completely free of device dependencies 
and absolutely free of physical path dependencies. 
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The general formats for logical I/O functions are as follows: 
introduc e (argl; acga) -> name 

- This provides a means for naming a source/siriK port object 
having the characteristics defined by the argument list. A 
name may represent a collective object thus allowing for 
broadcasting to all elements of that object. 

s en d-message (name (arg, .. etc.); msg)- > rnsgid 

- This sends a data object, msg, to the object called name 
some of whose characteristics may be temporarily modified by 
the argument list. 

- The rnsgid is returned by the system to allow for 
subsequent reference to this message if an answer is later- 
desired or an error condition results. 

w ait-mess a ge (name (arg, ..etc.)) -> (msg;msgid) 

- This allows the program to specifically wait for a message 
from the source object, name. 

- Again the rnsgid returned allows for a subsequent answer to 
be returned. 

send-answer (rnsgid) ---> answer 

- Requests an answer to rue message previously identified by 
rnsgid. 

w ai t- answer (msgid) -> (answer;rnsgid) 

- Only one of the rnsgid arguments is to oe used, ir the left 
or input argument is non-void, the process plans to wait 
until only that message is answered. Ir the ieit argument 
is void, then the system will return the first answer it 
receives and identify it with the rnsgid specified by the 
system earlier whan the message was sent. 

3.4.2.3.2 Physical i/0 

Physical I/O is defined to oe the data communication 
interface between the system and the CU which in turn 
interfaces with the real devices or other operating systems 
known to the AFS system, whatever tne source of a message, 
its format at this stage is m BDUs (Basic Device Units). 
Each message (or answer) can be represented cy a set of 
fixed length BDUs with emneaded sequencing information. 
Functionally they contain a device name, priority 


IBM CONFIDENTIAL 




( 


Chapter 3.4 


SYSTEM FUNCTIONAL MANAGEMENT 


149 


information, and a string or bits which is logically opaque 
to the CU. Correspondingly the system is unaware of the 
external location of the uevice/system or the path(s) to 
them. 


The BDUs reside on queues 
address space o± the SMU. 
extension to the normal 
information between objects 


of port objects in the logical 


These represent a consistent 
queuing mechanism ror passing 
ror processing purposes. 


3.4.2.4 Architectural Considerations 


| 


< 



The purpose of data communications is to seal and receive 
consummabie messages between two or more devices, systems, 
or application programs. These messages may oe explicitly 
initiated by a device/another system or application program 
or they may be implicitly initiated within the AFS control 
program to provide networx transparency. 

Explicit messages are essentially those between users either 
at devices or as a result oi writing application programs. 
Another system can oe thought of as just another type of 
device. Two things can effect a message; its path and the 
functions performed m between the sender and the receiver. 

It is the responsibility of AFS to make the path 
virtual/iocai/remote transparent. The functions are 
dependent on the characteristics of the senuer and receiver. 
For example, if both are just AFS application programs . 
(inter-AFS job communications) tnen the functions in between 
are essentially zero, i.e. just normal expression 
processing. On the other hand if one of the end points is a 
graphics device tnen there are considerable functions 
required to translate the data to an application program 
from the grid or the tube and perhaps its right pen. While 
logically these functions appear to be done in the device, 
cost/performance reasons may require that some of these 
functions be done in the' AFS control program. 

In order to maxe the pata or the message transparent, the 
system must handle various situations depending upon whether 
one end point relative to the otaer is in a native AFS job, 
in a virtual device or operating system, or whether it is 
locally or remotely attacaea. The first two situations are 
handled within the AFS control program. The last two are 
physical I/O and are handiea transparently to the control 
program by the CU. 

The followrng sub-sections translate these message function 
and path aspects into the services performed by the major- 
areas of AFS. 
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Before proceeding it snouid be stated tiiat AFS must be 
flexible enough to dynamically add/deiete devices, ana its 
associated Cll to correspondingly be able to make on-line 
changes m device types and the paths to them. 

3.4 .2 ,4.1 System 

The standard system inactions tor messages are those 
provided tor all expression evaluations. These are such 
things as name resolution, attnoute examination, and 
validation of authority. 

In addition, a unique system message identifier (nsgid) is 
created for each new message. It is retained by the system 
only white it nas responsmiiit y for the message and 
forgotten after delivery of the message to either an 
application program or a port object gueue which interfaces 
with the CU or a virtual devica/system. 

Standard inter-AFS job communications within the same system 
are independent of the Source/Sink (S/S) subsystem. In the 
case where network processing is required, the cooresponding 
subsystem desiring the mtoriaation interfaces with the S/S 
subsystem is the same way (except for airferent 
authorization) as an application program. 

Users of the S/S subsystem are unaware of whether the device 
or other system is co-existing in the same AFS system or 
not, and if not, whether it is local or remote. 

3.4.2.4.2 Source/Sink Subsystem 

This subsystem proviu.es a uniform interrace to all 
communications outside its system. Its responsibilities are 
to process the data so taat it is in a suitable logical form 
for the eventual receiver - device, operating system or 
application program. In the case of a device, it may mean 
special format processing auu/or internally cost/pertormance 
implementation of device functions. in the case of an 
operating system, it means tne protocol for communications - 
which by the way snouid oe trivial if it is to another AFS 
system. In any case, its internal system interface is in 
the form of BDUs {Basic Device Units) which are the logical 
interface to any particular device in question. 

At this point far down the processing path, the S/S 
subsystem finally resolves the question of virtual 
attachment. Its answer simply determines the port object 
queue tae BDUs are to go on or come from. 

The BDUs rundamentaliy ouly nave a device/system name, a 
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priority to aid algorithmic scheduling, and a string of bits 
represent the data iniormation. In addition, they will 
probably have a fixed u lock, format thus requiring some 
additional imbedded sequence number. The bits of data 
information will be logically opaque to the CU. 

The message queues for the port oojects will be located in 
the logical address space or the SaU, and the mechanism and 
interlocks with the CU will he essentially identical to that 
between other objects m tne system. One difference, 
however, is that since tne mrorination is being moved out of 
the SHU logical address space, the cell name for that will 
no longer be a suitable means of identification and, if 
going to another system, will have to be replaced by a 
prescribed network symbolic name. 

3.4.2.4.3 Communication Unit 

The CU is the interface or the system to the physical 
communication network. Its responsibility is to yet BDUs to 
and from aevrces/other systems for its own system. 

To do so it must know want devices are connected, the paths 
(lines) to them, and the protocol for tnose paths. In 
addition, it must determine tne optimal transmission hiock 
size, termed BTU-Basrc Transmission Unit. 

Opaque to the contents in tne BDUs, it may employ various 
compaction aigoritnms in conjunction with associated 
communication unit facilities on the network if it can 
improve cost/performance. 

Like the PPU, the CU may ne a multiprocessor. Furthermore, 
it may be connected to more tuau one system and conversely a 
system may be associated with more than one CU. In the 
latter case, an addrtiouax small amount of physical network 
awareness may get back into tne system design m order that 
it may have to decide wnat device goes with what CU. 

1.4.3 System Monitor Con tr ol 


System Monitor Control is responsible to monitor ail system 
operations and to cause recovery actions to begin in the 
event of system raiiure(s). in addition. Administrative 
Control (e.g,; statistics collection and customer ailling, 
etc.) and System Support Control (e.g.; dynamic system 
reconfiguration control, etc.) constitute important system 
roles of System Monitor Coutroi. 

The following is an enumeration of the Monitor Control 
categories; 
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3.4.3.1 User Orientation 

-Control of terminal user actrvities 
-Assignment of terminal user priorities 
-Degree of user/system interaction 

-System Operator aui Data Ease Administrator support 
-User Integrity 
-System service support 
-Billing 

-Performance analysis 

-Verification or proper system operations 
-Assigning passwords 

3.4.3.2 S yste m C onfigu r at ion Co ntrol 
-Startup and Shutdown of system 
-Set Priorities 

-Dynamically change priorities 

-Provide warning alarms on exceptional operating 

conditions 

-Line or specific terminal load exceeds pre-assigned 
maximum load 

-Terminal outage 

-Low priority messages are not Being processed 
-Data access reguests are not being honored 
-Unusual number or accesses to data base 
-Erroneous passworu 

-System monitoring support on specific system 

components 

-Server allocation 


IBM C0MFIDEMT1AL 




Chapter J. 4 


SYSTEM FUNCTIONAL ilANAGEhENT 


153 


-Gather and output usee statistics 

-Terminal load by time or day 

-Line load by time or aay 

-Errors by line auu terminal 

-Number of message by type by time or day 

-Response time by message type 

-Response time by time or day 

-Processing time by message type 

-Data access, deletion and insertion statistics on data 

base 


3.4.3.3 C he c kp oint Rest art 

-Automatic checkpoint! ug of the entire system based on 
a pre-defined criteria. 


-Checkpointing initiated explicitly by the System 
Administrator. 

-Reguested selective cneckpomting on specific Entity 
Record Sets initiated explicitly by the System 
Administrator. Ail active and/or pending processing 
requests involving the Entity Record Sets should also be 
checkpointed. 


-Restart capability (warm 
rest to initial state the Entity 
reconstruction 


start) wmch involves 
Record Sets updated and 


the 

the 


-A Restart capability (cold start) 
failure. 


after a catastrophic 


3.4.3.4 T erminal Me rwor s. 


-Enabling a line or terminal 
-Disabling a line or terminal 
-Selective termination of message 
-Selective termination of message 


handling 

processing programs 
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-Transmission control 

-Path Control 

-Message Delivery Control 

-Alternation of intermediate station characteristics 
-Alteration of Port Profile 
-Shutdown of a terminal 

-Enabling ana disannny of terminal (s) in exclusive 

mode 

-Security lock and unlock of terminal (s) . 

3.4.3.5 Data Base 

-Physical attribute descriptor table definition 

-Physical groupings or attribute values into Entities 
and Entity Record Sets 

-Physical data organization, access methods reguired 
and storage media spanned 

-Physical index tables to be maintained. 

-Dynamically establishing new complex logical data 
structures 

-Selectively inhibiting tne use of specific Entity 
Record Sets 

-Batch-mode of uata base maintenance and 
re-organization 

Control based on tne data content 

Control based on data access operations on data 

Security classification of Entity Record Set types 

Security classification of Entity-Attribute fields 
Security classification by level and by association 

Control over concurrent data access 
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historical versions of data access 

Transaction audit trail ou historical and/or current 
versions of data. 
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3,5.1 Backgrou nd 


This subject is probably the most difficuit strategic issue: to 
understand the relationship or a new, yet undetinea, system to 
that of present, and changing, systems. Because its impact is so 
broad - engineering, programming, customers - there is a tendency 
to delay decisions which, like ecology problems, unconsiously 
translate themselves into a default decision of incremental 
improvements until eventually the panic or crisis forces a major 
change. 

The Company's goal is to make profit on a continuous basis, both 
yearly and lony range. It predominantly mas.es that profit from 
engineering products, hence this is the major migration factor - 
and not programming. Obviously, programming is important to 
making the engineering products attractive, and tnus indirectly 
affects profitability. since programming is the primary user 
interface, it is also important to separate it as logically as 
possible from tne engineering to allow for easy introduction of 
new engineering products. 

The point being stressed here is taut programming migration item 
one operating system to another is a lesser, albeit, important 
factor than that of engineering product migration. It is 
essential to understand what reasibiy can be done to aid 
programming migration, and what cannot. hew system attempts in 
the past have burdened themselves with so many compatibility 
constraints that they lost their capability to introduce the new 
concepts that justified having a new system in the first place. 

There is another facet of these self-defeating myths, namely the 
one that says that anything conceptually new is too far out (i.e. 
ad tech) because it is so difficult to even extend present 
products - witness OS and DOS. what is generally rorgotten is 
that it is not the new functions tnat are conceptually difficult, 
but it is the unsuitable system structure, present low functional 
engineering interface revels, and the lack of programming 
interface control that are the primary inhibiting factors, 

A product ship "window” can be roreseea around iy77 tor an 
opportunity to make a major system architectural change with the 
combination of the ending of S/370 CPU/maiaory product lives and 
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the advent of LSI components. ine subsequent portions of this 
section attempt to define the major issues involved in taking 
advantage of that "window" to introduce a system base which at 
this time has the possibility or being an ".ultimate” one - from 
technical intuition, ability to aajust to both user functions and 
introduction of new engineering products, and from the eventual 
"defined by enertia" effect. These factors coupled with the 
increasing obvious "aging" of present operating systems to 
changes should give rise to serious management reflections if we 
do not take advantage of the F3 "window". 


3.5.2 I ss ues 


There are a number of issues mat need to oe realistically 

appraised to best understand tae tradeoffs over time that need to 

be made to get AF3 introduced into me marketplace. 

- First of ail, a thorough evaluation effort for AFS from 
all facets of rail is essential to gam the best system base 
possible. in particular, a strong central system 
architecture group will be required to ensure that a 
consistent set of tradeoffs is made to maintain for new 
market requirements and technology. 

- AF3 will have a new program SCPI (System Control Program 

Interface), which wiii be different from OS ana DOS. It 

should be realized tuat even a new S/37 0 - based FS 

operating system would also need a new SCPI. As a result, 
program migration must be as a result of at least 
re-compilation. It agreement on the common intersection of 
the feasibly possible user interfaces (HLL, CCi, FDL, and 
DDL) was obtained (in 1972?), then emphasis could be made to 
direct users to that common set during the interim. A 
corollary of this which needs to be accepted is that many, 
probably the majority or programs, will not be easily moved 
oy re-compilation. These m particular include the major 
system efforts to take full advantage of 5/360. 

- Because of the marketing ractor that FS PPUs oust replace 
5/370 CPUs, and because of the level of incompatibility 
between the two (in spite oi the above HLL, etc. 
compatibility erforts), co-existence oi present operating 
systems is essential. Furthermore, a basic co-existence 
capability is required (with a 2:1 cost/performance) which 
still allows for an attractive perrormance lure to AF3. The 
tradeoffs between these two are some of the most critical 
needed to be made. 

- Second generation IBM systems (I4xx, 7 0xx) should only 
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have to be simulated on S/SoO under OS or DOS and hence have 
no direct impact on either the Si. or engineering units of 
AFS. 

An unresolved issue is the abiiity/need to have 
co-existence of GSD systems. 

Another unresolved issue is the ability/need to have 
co-existence of non-ISM systems. 

The ability to dynamically interchange information 
logically between AFS and otner operating systems should 
only be by means of a formal networking protocol. This will 
provide native (co-existence) , local, remote transparency to 
users of these systems as well as limit the impact of 
co-existence of the other systems on the structure of the 
AFS control program. 

Co-existing aou-AFS data, along with programs and 
operating systems, must also be controlled by AFS. 
Logically this data is owned by their own operating systems 
and requested via the networking interface if used by a job 
running on the AFS control program. Physically, the data 
may be stored in the SMU or via a S/370 interface to 
individual storage devices. Individual devices will only be 
used by native non-AFS systems. They are of two classes: 
those that can also work in tne SMU and tnosa that cannot. 
Hon- AFS data can be moved in an application user 
transparent manner ori tne possible SMU devices into the SMU 
after which tne devices can be added to the SMU. The older 
storage devices including tapes, which are not possible to 
be put in the SMU, can remain until their cost/performance 
is low enough at which time their data can also be moved 
into the SMU and these devices removed from the system. 

Source/sink equipment, witu the proper interim product 
plan, should be able to directly connect to AFS via a 
27HN-iike Communication Unit (CU) . Present operating systems 
should evolve as much as possible towards the data 
communications architecture concepts outlined elsewhere m 
this document. In particular, native systems should act as 
ir they had a CU attached to them - thus providing a clearer 
interface to the Source/S nut (S/S) subsystem of the AFS 
control program. 


3.5.3 C ourse of A ctio n 

The general course of action at this time is to develop the broad 
technical understanding of AFS architecture; realistically 


IbM CONFIDENTIAL 



Chapter 3.5 MIG HAT ION, 


CO-EkiSTiiN CE, IHXEHCHA NGE 


159 


appreciate what cau he done to am a 
and then seek to take advantage or 
both our spectrum o£ engineering ana 
customer community to ease the tra 
into the marketplace. 


lyratron and 
the interim 
programming 
ns is t ion of 


than tradeoffs; 
time to prepare 
products and the 
introducing AES 
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THE (lAN-ilACiiiNE INTERFACE IN AFS 


This part of the report is to become a description of AFS in 
terms of the basic infix fora. The user who wants to learn to 
use the system without probing into its inner wordings may do so 
by reading only this part. Ac present, only two chapters have 
been started. Chapter 4.3 describes the functions and syntactic 
markers, and Chapter 4.5 presents examples of SL programs. 


,1 

f •' 
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SOAH ANY. OF 3A3IC INFIX FOSE 


4.3.1 I n t rod uc ti on 


In this chapter, the runctions and syntactic markers are 
described as they are used in the basic infix form or 3L. This 
is the form that people usually want to see and to think, about. 
Compilers will usually produce the strict form, so a few people 
will be interesteu in seeing strict form. Ine following 
expression is written each way: 

(a*b) (c + d) stow e 

stow (sum (guotient (a; b) ; sum (c;) j ; e) 

The basic infix form is described in terms of tue strict form in 
which the primary description or SL has been given. Eventually, 
this chapter will become a programming manual and wiii contain a 
partial repetition of a description of the semantics of SL so 
that a programmer who chooses not to delve below the basic infix 
level will not have to do so. For the present, however, only 
enough semantics is given here to guide the reader wno has read 
the previous chapters at least cursorily. 

In particular, tne syntactic form or program text is uiscussed in 
2.2.2. Some readers wrii fina it neipfui to review that section 
before reading the following descriptions of functions. 

Some syntactic markers have tue form or runctions, so they are 
included in this exposition without further ado since they have 
syntactic properties like those or true functions. Included also 
for completeness are certain other syntactic markers which are 
guite different: parentheses, braces, semicolon. These are 
listed in alphabetical order with the other syntactic markers and 
with tne functions, it may be heipiul to read tnese first. 

The following examples explain tne rules used to translate 
n-adic function and syntactic marxer definitions from strict 
form to basic infix form: 

f (x) becomes f x 

f{x;y) becomes x f y 

i{x;y;z) remains f{x;y;zj 
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If the function naie is aipha oetic, blanks must be used to 
delimit it. 

blanks may be used freely throughout SL in most reasonable 
places. They may be piacea oerore or after any nou-alphanumenc 
character that represents a runction or syntactic marker, or they 
may be omitted. At least one clank must be used to separate 
adjacent alphanumeric symbols. waerever one blank may appear, 
any number of blanks may be used. Blanks must not appear in a 
symbol, in a function represented u y something produced with more 
than one key stroke, or in a constant that is not a character 
string. 

At present, evaluation is iert to right, and taere is no 

precedence except that semicolons, parentheses, braces, and 
brackets are considered to delimit expressions. More precedence 
relations may be introduced m subsequent editions. 

There are two classes of symcois: function symbols that 

represent functions requiring arguments and elementary symbols 
that represent objects that do not require arguments m order to 
be evaluated. In the strict toriu, the syntax of the expression 

in wnich the symbol occurs indicates the class to which the 

symbol Delongs. In the basic innx form, the notation is more 
concise and the class of a symooi is not indicated by the syntax 
of its use. Instead, the class is recorded in the dictionary of 
the module, and it is determined by the definition or the symbol. 
If it is defined oy a lambda expression with one or mere 
arguments, then it is a function symbol. If it is defined by a 
functional that has function symuois as arguments, then it is a 
function symooi. Otherwise, it is an elementary symbol. (Ref. 
2 . 2 . 2 ) 

Eventually, many runctions ana syntactic markers will be 
expressed by single characters. For this exposition, however, 
most of them are represented by mnemonic names or abbreviations. 


In certain cases a familiar character has been used (like + or 
*) • 


4.3.2 Common abbrevra t i ons 


The form used to describe a function or syntactic marker includes 
a ’’where” section that defines notation, variables, etc. Certain 
very common abbreviations are defined here for once and for all, 
and the definitions are omitted m the many operator definitions. 
The following are syntactic variables that stand tor instances of 
classes of character strings. Two instances of an abbreviation 
m a single expression do not necessarily stand for the same 
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string. If they do, a digit will i>e appended (e. g. , stmt3) , and 
the same digit krill he appended in two instances that refer to 
identical strings. 

abbreviation stands for 

expression 
s tat erne n t 


expr 

stmt 


4.3.3 Alphabet r e al List ing of Funotions and Sy nta c ti c Mark e rs 


Eventually, this section will become a programming reference 
manual with every function ana syntactic marKer described. At 
present, the functions listed m section 4.3.4 are not described. 
However, the reader who is familiar with APL can understand them 
well enough from their names and rrom the introductory remarxs in 
4.3.4. 

Section 4.3.5 lists functions that are defined elsewhere or not 
defined in this report. 

Section 4.3.o summarizes the situation. 

Section 4.3.7 gives a preliminary rough analysis or the 
complexity of SL, judging it in terms of the number of functions 
and syntactic markers required. 

The functions and syntactic markers are arranged alphabetically 
with the names in the bottom title. 

The examples given at the top or each page are intended to be 
exhaustive and to cover ail possible uses of the symbol being 
defined. This goal aas not been achieved in Edition 3. 
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examples: 

where: 

value: 

side effects: 
use: 

comment: 


Seferences: 


apply 


THE MAN-MaCHINE IHTSRPA.CE IN APS 


y apply a 

a is an ordered list of symbols like (x;y) # or it 
is a single sytnooi. 

y is an expression whose value is an unevaluated 
expression or uuevaiuatea group of statements. 

The value of the iast expression evaluated. 

None 

In the examples: Tne dyadic apply applies g to a. 

The implicit invocation mechanism is occasionally 
inhibited by built-in mechanisms to prevent 

ambiguity. Sometimes, the programmer 

intentionally inhibits the invocation mechanism so 
as to be aoie to manipulate an expression or group 
rather tnan just its value. Nhen this is the 

case, it is clear from the definitions of the 
operators involved. The purpose of apply is to 
execute code whose invocation has been inhibited. 
The dyadic apply function also associates 
parameters with the function it invoices. The 
monadic evai periorms this function without 

associating parameters. 


i» 2t • 6 , 1« o. g. 1 , eval 
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example: 

where: 

value: 

side effects: 
use: 

comments: 


References: 


SUMMARY OF 34SiC INFIX FORM 


r authorize x 

(evaluates 6 copies) authorize x 
x is an object. 

r is a rights expression. The allowable rights 
are tae present tense third person singular verb 
forms of the names of the requests that may be 
made on an object: authorizes, copies, deletes, 
destroys, evaluates, identifies, inserts, selects, 
starts, and stows. To authorize ail rights 
available m the right argument, specify "all”. 

A synonym that provides authorization tor access 
to x. 

The synonym, an object, is created. 

A synonym is line a pointer, but it has safeguards 
so that it cannot be used except ny requests with 
the proper authorization. Uaiixe a pointer, a 
synonym automatically passes all authorized 
requests to the object to which it points, whereas 
a PL/I pointer requires a further operation on it 
to produce a value. 

Synonyms and metonyms are accessors. it is not 
possible to convert any other data type into an 
accessor. This protects the system integrity from 
incursions of the sort that can no accomplished by 
adding integers to Ps/I pointers in OS/360. 

It is possible to convert a synonym to a metonym 
by the enclose function, and vice versa with a 
disclose runction. 

The authorization conveyed by a synonym is the 
authority to use functions that use requests 
corresponding co the rights m the rights 
expression. Notice that the names of the rights 
are tae nrst person singular verb forms of the 
corresponding request names. 

An authorize expression that attempts to convey 
rights not possessed by tae object will raise an 
error exception. 

Synonyms ana metonyms are needed by data base 
applications. 

x.1.5, 2.1.4, 2.o.3.5, sya 


authorize 
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examples: 

value: 

side effects: 
uses: 


Comments: 


References: 


THE dAN~flACdIME INTERFACE IN AFS 


{stmt ;stmt; stmcj 
f £stmt;stmt;stiat{ 

{expr} 

The value of a group of statements delimited by 
braces and semicolons is a collective object {a 
list) whose elements are the statements. 

None 

A pair of braces delimits a portion of code and 
inhibits the implicit evaluation mecaanism. 

A specific use or a pair of braces is to delimit a 
group of statements in order to use the group as 
an argument of a function. 

Another specific use is to enclose an expression 
so as to mnibit the action of the implicit 
evaluation mecaanism. 

A pair of oraces may be used in Si to perform the 
function of bES IN ;....; END ; or DG;...,;£ND; in 
PL/I, A new environment is created for a group 
when it is lavoned it and only if some function in 
whose arguments tne group appears or seme 
statement in tne group requires an allocation of 
storage that is local to tnis invocation. 

braces can only be understood if one understands 
semicolons and pa rentaeses. See first the page on 
delimiters and tiieu the pages on semicolons and 
parentheses. 

braces are syntactic markers that no not appear in 
the code that tne machine executes. 


1.2.2, delimiters, semicolon, parentheses 


braces 
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examples: 
where: 

value: 

side effects: 

use: 

comments: 


References: 


p conditional expi 

p is a predicate, an expression whose value is 
true, 1, or false, 0. 

When the value or the left ary ament- is 1, the 
value of the expression rs the value of the right 
argument. When the value of the left argument in 
0, the value of the expression is mi since it is 
not executed. 

if tne left argument is 1, control returns from 
the group. This is like tne PL/I HEIUhh-statement 
which causes control to return trom a block. If 
the value of tne left argument is 0 the expression 
has no sine effects. 

To terminate the evaluation of a group 
conditxonaily. 

The conditional provides the means to express 
condrtxonai expressions. It wrii probably be 
represented by a single cnaracter. In this case, 
nested PL/I IF THEN ELSE statements, and LISP 
conditional statemeucs will be handled concisely 
and elegantly. 

2.2.7, exit 


conditional 
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example; 

where; 

value: 

side effects: 

use; 

Reference: 


create 
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p create x 

p is a procedure description, 
x is an object. 

An internal identifier of the object it 
constructs. 

It constructs an object which has, in its access 
machine, p as its procedural description, and a 
process status record and interpreter that are 
appropriate to p. i’he resource of the object is 
a copy of the resource of x, translated to fit 
the new access machine. 

To construct adjects usinj software procedure 
descriptions. 


2 . 6 . 1 . 1 
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where: 

value: 

side effects; 

use: 

comments: 
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declare x y z scop static; 

p unique; 

a b c new automatic 

{stmt; stmt; stmt; stmt; stmt} 

declare d g 

d is a list of scope and storage class 

g is a group of statements. Among tnese may be 
statements that affect access machines, in other 
words, declarative statements, otner than those 
that atfect scope and storage class. 

The value of tae group, in other words, the value 
of the last expression evaluated before control 
exits from the group. 

The variables listed in the space between the 
declare marker ana the group have the attributes 
mentioned. 

To majte scope and storage class declarations. 

The need to separate declarations of scope and 
storage class from other declarations is a result 
of the fact that SL is a machine language and the 
basic infix form is not rearranged before being 
executed. In the extended infix form declarations 
wili probably be more lute those in PL/I. 


declare 
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examples: 

where: 

value: 

side effects: 

use: 

Reference: 


i delete x 

X is a collective ooject. 
x xs a meaner of the index set of x. 

The erstwhile xth member of x 

Tne storage cell corresponding to i is removed 
from its inaex set. 

To delete storage cells from tne resource of a 
collective object. 

2 . 1.6 


delete 
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examples: 


uses: 


comment: 


deferences: 


{strnt;stmt;stmtj This is the external 

representation of a collective 
object# a list of three 
uuevaiuateu statements. 

f(stmt;stmtjstmt)This triadic function is 

interpreted as a monadic 
function that taxes as its 
argument a list of the values 
of the taree statements. 


g {stmt; stmt;stmt} This is a monadic function 

that taxes, as its argument, a 
list of taree unevaluated 
statements. 


a 4- (b + c) 


The denominator is the value of 
the sum. 


{exprj 


The braces inhibit the implicit 
invocation mecnanism. 


A pair or parentheses delimits a portion of cede 
and does not inhibit the implicit invocation 
mecnanism. 


A pair ot braces delimits a portion or code and 
inhibits the implicit invocation mechanism. 


Semicolons delimiting the constituents of a 
portion of code, delimited uy oraces or 
parentheses, indicate that the constituents are 
the elements oi a list. 


These delimiters dre shown together on this page 
to illustrate the symmetry. For details, see 
references. 


braces, parentheses, semicolon 


delimiters 
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examples: 

where: 

value: 

use: 

comments: 

References: 


THE MAH-MACHiNE 1H fEHFACE Id AFS 

dxsciose m 
disclose n ♦ 1 
disclose x 

m is a metonym for an object y. 

n is a metonym tor a floating point number x 
for whrch there is a synonym s. 

y is a collective object. 

x is enclose y. 

a synonym for y, if the argument is a metonym. y 
if the argument is enclose y. 

A metonym is a pointer and disclose is used to get 
at the value it points to. 

In the second example, n+1 would raise an error 
exception, whereas s+1 would compute the sum 
correctly. Mote that (disclose n+1) = (rn+1), and 

that (a+ 1) = (x+ 1) . 

For any object x, disclose enclose x = x. 

2.1.5, 2.1.7, enclose 


disclose 
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examples: 

where; 

value: 


uses: 


comments: 
References: 


enclose x 
x is an object 

If x is a collective ooject, the value is a 
scalar object that contains the collective object 

x. 

If x is a synonym, the value is a taetonym. 

In the first case, it is used to make it possible 
to compare characters instead of bit vectors or to 
compare words iusteaa of charactor vectors. 

In the second case, it is used to rnaxe metonyms 
which are like PL/1 pointers. 

For any onject, x, disclose enclose x = x. 
2.1.5, 2.1.7, disclose 


enclose 
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examples: 

where 

value: 

side effects: 
use: 

comment: 

References: 


THE MAh-aACHiMiS IN TBHtACE it) AFS 


evaluate g 

g is an unevaluated group of statements or and 
uaevaiuated expression. 

The value of the last expression evaluated, 
none 

To execute an expression or group when the 
implicit invocation mechanism has been inhibited. 

See the comment under apply. 

apply 


evaiua te 
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examples: exit expr 

value: The value of exit is the value oi the expression 

that is its right argument. 

side effects: if the exit statement occurs m a group, control 

returns from the group. This is luce the effect of 
tne PL/I RETURN-statement which causes control to 
return from a hiocK. 

use: To terminate tne evaluation of a group. 

References: 2.2.7 
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example: 

where: 

value: 

side effects: 

use: 

comment: 


deference: 


IHjS MAN—MACrilN B UTEdFACE IM AFS 


goto s 

s is a symbol tnat a as been used as a label or an 
expression tnat nas the value of such a symbol. 

The goto statement is not a normal expression and 
does not have a value. 

See comments nelow. 

The goto generates a sequence exception which is 
handled by the monitor. Tae next expression to be 
executed is tue one whose iaoei is the right 
argument or goto. 

To perform the function of goto or branch in 
object code produced in translating from other 
languages. 

goto is not necessary for programs written in SL. 
Many users will prefer to eliminate it rrom the 
repertoire of functions available. 

If it is feasible to label expressions as well as 
statements, and if it is feasible for a goto 
statement to nave the value of the last previously 
evaluated expression, then the goto will provide a 
particularly powerful tool. however, this 
capability will not be added if it implies 
significant cost increase or performance 
degradation. 

label 


goto 
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example: 

where: 

value: 

Side effects: 
use: 

comments: 

Reference: 


ibase x 
x is an array 

The index oase of the array x which is a list of 
lists. The ith sunlist is a list of the values 
that the ith element of a meaner of the index 
set may taxe, and they are listed in order of 
increasing value. 

The list of lists is created. 

To generate the index case. 

The abbreviation roase stands for index base. 

2.1.7.3 


ibase 
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example; 

where: 

value: 

side affects; 
uses: 


THE MAN-MACHiNE XNTEhFACE IN AFS 


ige aerator s 
igenerator 

s is a irst of positive integers. 

A list of lists of integers. Each sublist is a 
primitive index set (i.e., 0, 1, 1»....,a), and 

the number of elements of tne kth sublist is the 
kth element of s. 

The list of lists is created. 

To generate tne inaex base for a primitive array 
from the shape of the array. 


igenerator 
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examples: 
where: 
value: 

side erfects: 
comments: 


Reference: 


ilist x 

x is a collective od ject. 

A list that is a copy of tne index set of x. 
Production of tne copy. 

If x is a vector, ilist x is the same as the 
APL expression iota rho x. 

Tne abbreviation H iiist’' stands for "index list”. 
2. 1. b 


ilist 


IBB CONFibRNflAL 


ilist 




180 


THE MAN-EACtiiME INTERFACE IN APS 


example: i insert x 

3 replace (i insert x) 

where: i is an object, not in the index set of x but 

suitaole to ne added to it, or it may be the 
object nil. 

x is a collective object, 

value: An implicitly defined synonym of the i component 

of x. 

side affects: (1) A new storage cell is added to x. 

(2) i is added to the index set of x. 

(3) i is mapped onto the new storage ceil. 

(4) A copy of under is piaced in the cell. 

use: An important use is the one illustrated m the 

second example whica adds an obgect, a storage 
cell to put it in, and a meiaber or the index set 
of access it with. 

comment: The new mernner is added to the end of the index 

set, if tne index set is ordered. To move it 
elsewhere, a suoseguent application of ro ta te will 
do so. 


If i is already a memoer of the rudex set of x, 
or if r rs not nri and not in tne admissible set 
of indices tor x, an error exception rs raised. 

fieferances: 2.1.7, 2.6.3.2 


A 
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example: 

where; 

value: 

side effects: 
use: 

comments: 


s:expr 

s is a symbol. 

The value of s;expr xs tne value of expr. 

The symbol s oecomes a label of expr. 

To attach labels to expressions so that they may 
oe the target of a goto function. 

The colon xs a syntactic mar her that xndicates 
that some symool is a Iaoei and indicates the 
expression that it iaoels. 

A laoel is a read only value initialized at 
compile time. 

Labels appear to be useful primarily for object 
code created by translators from other languages 
and uot for native mode SL programming. 

Possibly, it will be found that only statements 
can be iaueiea, ana that it is too costly to be 
able to laoel expressions msiae statements. 


label 
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examples: 

where: 

value: 

Side effects; 
use: 

commeuts: 


deferences: 


THE MAH-MACHINE INTERFACE IN AFE 

\ 

a lambda y \ _/ 

( x ; y ) lambda {stm t;st mt ;stmt) 
a is an orderad-list of symbols, 
y is a group 
x and y are symbols. 

An a-adic function where u is the number of 
symbols in the left argument. 

s» 

None 


A lambda expression may be assigned to a symbol, 
making it a function symbol. Alternatively, the 
lambda expression may be used in place of a 
function symbol in an expression. 

The lambda expression is the means, in SL, to 
extend the functions available. SL may be 
extended m data types by defining new access 
machines. To accommodate new data types, cld 
functions must be redefined by assigning to them 
the value of an appropriate lambda expression. 

The names or tae arguments of the function are 
given in the symbol list in the order in which 
they must appear in an expression that uses the 
function, 

2.2.3, 2.6. 1.2 


A. 


lambda 
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examples: 

where: 
value: 

side effects: 
use: 


References; 


parallel g 

parallel {stmt; stmt;stmt) 
g is a group. 

A vector whose elements are the values of the 
statements comprising the group. 

None 

To state that the statements comprising the group 
may be executed in parallel or m any order the 
machine selects. 


1. 2* S g 2.o. 9.2 


parallel 
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examples: 

value: 

side effects: 
use: 


comments: 

References: 


TtiJS dAN-ttACHiM si lAXiSRFACb IN Aid 


f (stmt; stmt;stint) 


a/ (b+c) 

Parentheses do not inhibit the implicit invocation 
mechanism so the value of a portion of code 
delimited by parentheses is either the value of an 
expression or a list of values of statements. 

None 

A pair of parentheses is used to delimit a portion 
of code without inhibiting the implicit invocation 
mechanism. 

One specific use or parentheses is to control the 
order of execution of functions in an expression. 

Another specific use or parentheses is to delimit 
the argument list of an n-aaic function when n 
is greater than 2, and when, as is usually the 
case, the arguments are to be evaluated before the 
function is evaluated. In SL, such a function is 
interpreted to be a monadic function that takes 
the argument list as its argument. 

To understand parentheses, it is necessary to 
understand the semicolon and braces. Read first 
the page on delimiters and tnen the pages on 
parentheses, braces, and semicolon. 

delimiters, oraces, semicolon 


parentheses 
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example: 
where: 
value: 

side effects: 

use: 

Reference: 


SUMMARY OF lih'JlC INFIX FORM 


remove x 

x is an object, 

x 

A copy cl under is piacea in the storage cell so 
that if x is evaluated again, an error exception 
is raised. 

To remove the contents or a storage cell without 
destroying the ceil, 

2 . 1.6 


remove 
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remove 



I 

i 

1 bb 

examples: 

where: 

side effects: 
value: 

use: 


References: 


repeat 
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p repeat g 

1 stow x ; (i< 10) repeat (x + 1 stow x; stiat ;stmt; stmt] 

p is a predicate, aa expression taat evaluates to 
1 or 0 

g is a group or statements 

x is an integer 

Rone 

The left argument xs evaluated. If its value is 
one, the argument on the right is evaluated. Then 
the left argument is reevaluated and the cycle is 
repeated. If the value of tne left argument is 
zero, execution ends. The value is the value of 
tne last expression executed in tne right 
argument. it the right argument is not evaluated 
at all, the value is nil. 

The second example is equivalent to , in FL/I: 

DO 1=1 TO 1u ;stmt ;stmt;stmt; ERi); 

The exteuaed infix form will probably have a 
DO-statement of this sort. 


2*2,71 2.o.g.l 
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examples: 

where: 

value; 

side effects; 

use: 


comments: 


x replace y 

x ana y are objects 

The value is a copy of x. 

The object y is destroyed, unless y refuses to 
destroy itself. In lu is case, y remains unchanged 
and an exception occurs. 

Usually replace is used when one argument or the 
other is an expression that has the value of an 
object. Then it is possible to make an object 
that is a copy of a component of another object or 
by using insert, to aad a copy of an object as a 
new element of another object. 

Notice that replace changes tne whole object, 
both access machine and resource. Stow, on the 
other hand cuanges only the resource. 


References: 1.1.7, 2.6.4 
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replace 


replace 



iaa 


examples: 


where: 


value: 


comment: 


References: 
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,/f 


i 

select x 


± 

select x stow y 


X 

is a collective ooject. 



i is a member or a synonym for a member of the 
index set of x. 

y is an object whose access machine is suitable. 

An implicitly uefiued synonym for a member of the 
right argument whose index is the left argument. 

Select does not create a copy but merely 
identifies some part or parts or the collective 
object that constitutes tne right argument. To 
create a copy, it is possible to use a stow 
function as in the second example. In this case, 
the target y must have an access machine that is 
suitable tor the ith element of x. 


2.1.5, 2.6.3.1 
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examples: 

value: 

side effects: 


comments: 


References: 


SUMMARY OF OARiC INFIX FORE 


{stmt; stmt; stmtj 
f(x;y ;z) 

Semicolon does not have a value. 


The semicolon is a delimiter whose precedence is 


lower than any function 
expressions are adjacent, 
and the other must be 
However, if a semicolon 
two elements of a list, 
statemen ts. 


or functional. If two 
one must be an operator 
one of its arguments, 
intervenes, they oeccme 
As such, they are called 


The difference between a statement and an 
expression is tnat a statement is a member of a 
group of statements and then, when the group is 
evaluated, tne value of a statement is discarded 
after the execution cursor passes the semicolon 
and before evaluation of the next statement 
begins. 


The semicolon is used to delimit the arguments of 
an n-adic function when n>=3. The comma is not 
usea because it is reserved to be used as the name 
of a function. 


To understand the semicolon, it is necessary to 
understana braces and parentheses. Read first the 
page on delimiters and then the pages on braces, 
parentheses, ana semicolon. 


2.2.2, delimiters, braces, parentheses 


semicolon 
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example: 

where: 

value: 

side effects: 


shape 


THE ilAN-HACliiHE ihTHuFACE IN AF3 


shape a 
a is an array 

A list of integers of length r where r is the 
raait of the array (the member of dimeusioas) and 
the ith element in the list is the size of the 
ith dimension of the array. 

The list is created. 
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examples: 

where 

value: 

side effects: 

uses: 

comments: 

References: 


x stow y 

x and y are objects or are expressions that have 
the value of objects. 

The value is an object that has tne access machine 
or y and the resource of tne value of x. 

The left argument is evaluated. Then, the right 
argument is evaluated. Finally, the resource of 
the value of the right argument replaces the 
resource of tne vaiue of the left acg ament. 

Thrs rs the normal assignment tnat taxes place in 
languages like PL/i. 

To produce the xina of assignment that appears in 
API see replace. 

2.1.4, 2.3.5, 2.0.4 


stow 
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example; 

where: 

value: 

aide effects: 
use; 


comments: 


THE MAH-£S AC HI ME Ifiif EHFACE La AFS 


syn x 

x is aa object. 

A synonym that provides authorization for access 
to x. 

The synonym, an abject, is created. 

A synonym rs iixa a pointer, out it has safeguards 
so that it cannot be used except by requests with 
the proper autnorization. Unlike a pointer, a 
synonym automatically passes all authorized 
requests to the object to which it points, whereas 
a pointer demands a further operation on it to 
produce a value. 

It is not possible to convert data of any other 
kind to a synonym. This protects the system 
integrity from incursions, sucn as can be 
accomplished by adding integers to PL/I pointers. 


To generate a synonym with fewer rights than one 
already has it is necessary to use the authorize 
function. 

Synonyms are needed for data base applications. 
2.1.5, 2.6.3.5, 2.1.4, authorize 


References: 
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4.3.4 A PL F unctions to he lap l-a seated in Hardware 


From the preceding discussion and a Knowledge of APL, the 
approximate meaning of the following will he oovious. There are 
a total of 59 functions m this category. Notice that some APL 
functions are defined elsewhere and are not listed here. The 
hyphen indicates when a dyadic and monadic function are related. 
»ihen the SL name differs from the APL name, it is snown in 
parentheses. 


Monadic 

Dyadic 

plus 

plus (sum) 

reciprocal 

divide (quotient) 

negative (minus) - 

minus(difference) 

signurn 

times (product) 

ceiling 

maximum 

floor 

minimum 

exponential(exp)- 

po we r 

nat log (In) 

log 

magnitude 

residue 

sin 

and 

cos 

or 

tan 

nand 

ar cs in 

nor 

arccos 

less (it) 

arctan 

not greater(ie) 

sinh 

eguai (eq) 

cosh 

not less (ye) 

tanh 

greater(ye) 

arcsinh 

no t equal (ne) 

arccosh 


arctan a 


not 

taxe 

membership 

drop 


reshape 

ravel 

catenate 

reverse 

rota te 

transpose 

transpose 

grade up 

com press 

grade down 

expand 

pi times 

outer product 

reduction(red uce) 

inner product 


someone might argue that the circular functions are just one and 
not 13 functions. From one point of view, they are 13 functions 
with hard-to-rememher names. 
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4,3.5 SL Func tions Defined Eiseanete 


The following 38 functions are defined or identified elsewhere in 
this report: aqurre, augment, oase vaiue, claim, connect, copy, 
delay, delayed parse, destroy, free, identify, ignore, index, 
inject, insert symbol, introduce, list, load, locate, map, 
member, monitor, name value, point, priority, guotient_reaainder, 
release, representation,send answer, send message, signal, step, 
suspend, translate (dyadic) , translate (monadic) , ultimate, unique 
name, wait answer, wait message. 


4,3.6 Su m mary of Functions So Far I a-dentiffed 


Defined in 4.3 

28 

Identrfied by aPL 

59 

Indentitieu elsewhere 

38 


125 


4.3.7 A Measure of SL Comple xit y 


The complexity of SL can oe measured roughly by comparing it to 
APL wnich performs a much more constrained function but has large 
areas of similarity. To do this The APL functions that remain 
will be dientified. 

There are 8 APL functions that nave clear conterparts among the 
SL functions mentioned; branching (goto) , function 

definition (lambda) , local vananie identification (declare) , 
specif ication (replace) , sire (shape) , trace controi (monitor and 
ignore), label (iabei) , indexing (select) , comma (augment) . 

There are 50 more APL functions to do things tnat SL will do but 
the relationship is not direct either Because the details have 
not been worked out or because the work is done differently. In 
some cases the work is actually done by functions already 
identified. These are: edxtrng control, editing mark, display 
controls, locked function, stop control, terminal input, 
character input, 34 system commands, 9 system dependent(I-beam) 
functions. In SL all of these things wiii be done with the kind 
of functions so far identified. Taeie will not be the diversity 
seen in APL/360. 

Finally there are 9 APL functions that will probably be 
programmed: 
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encode decode 

factorial omoiaiai coerticieut 

roil deal 

three square roots 01 sums of squares 

No decision has been made as to which of these marginal APL 
functions belong m the basic mux level of SL and which should 
be programmed. It may be, for example, that none of the circular 
functions will be in the machine language. However, all of them 
will oe in the extended infix form and ail or them will be 
supported where they appear m tae various favored high level 
languages. With this information, the languages can be compared 
as follows: 


APL/360 functions with direct SL counterparts 67 

APL/360 functions SL will cover 50 

TT7 

APL functions to be programmed y 

126 

SL functions with clearly defined APL counterparts 67 

Other identified SL functions 56 


125 

Clearly more runctions will oe auaed to SL, However, it seems 
clear tnat SL will be oniy a little more complicate! that APL/360 
while providing much more capaoility. 
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EXAMPLES OF SL PROGRAMS 


V. 


This chapter demonstrates the suitability or S.L as a target 
language for the translation of programs from PL/I, COBOL, 
FORTRAH, APL, RPG and LISP. For each of taese languages, typical 
program constructs are illustrated (along with contextual 
information when appropriate) and followed by an equivalent SL 
construct. The SL examples given are written in the basic infix 
notation (refer to Section 4.J). 

Programs written in SL to accomplisu these same purposes would be 
much simpler since they would not involve the complexities of the 
various source languages. 


4.5.1 Tr an sla tions from PL/I 

Example of simple case or PL/I uo statement: 
DO I = 1 TO 10; stateaent_iist; ERo; 

The SL code for the above is: 

3->I; (1+1->I<10)repeat[statemeut_listj 


In a somewhat more complicated case with various data types 
involved in the iteration calculation, there can be rounding 
problems that prohibit tne simple iuitra lizatron used above. 
Furthermore the value ol the iteratron irmrt can be caanged 
during the iteratron so tnere must be a temporary. .In this 
case: 

DO 1=1 TO N; 

statement_list 

END; 

Equivalent SL group: 

(declare C unique; 

(0 stow C; 

(eva 1 (C select ((1 stow I } ; 

(I sum 1 stow I ie R stow Cj 4 
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} 

i repeat (statement list) 

} 

} 


The general case of the PL/i DO statement is much more 
complicated than the ordinary user realizes, or can utilize 
often. A full explanation or the interaction or the TO and BY 
clauses with the WHILE option, with more tnan one specification 
present, may he found in the PL/I Language Specifications 
manual (131-6003- 1, pp 144-146) or the PL/I (f) Language 
Reference Manual (028-6201-1, pp 3o4-3o /) . This general case 
can oe programmed in SL using a single sxeieton (with the 
possibility of repeating one section as tne multiple 
specifications require), substituting for the names of the 
variables used in the DO statement. An example of this is shown 
below: 


DO I = J1 TO K1 BY LI WHILE (si), 
J 2 TO K2 BY L2 WH1LE(E2), 


• * • 

statement_list 

END; 


f 


Equivalent SL group; 


{declare U V A C BODY TEST unique; 
syn £stateiaent_list) stow bodi ; 
syn{signum V is 0 se.lect(I ie U;I ye U]j 
(0 stow C; 

syn£eval W and El] stow TEST; 

£eval{C select £ £K 1 stow D;L1 stow V;J1 

£1 sum V stow I; TEST 


} 


i 


] repeat BODY 

J; 

£0 stow C; 

syn£eval W and EZj stow TEST; 

£eval £C select ££K2 stow U;L2 stow V;J2 

£1 sum V stow I; TEST 

} 

} 

] repeat BODY 

}; 


stow W; 

stow i;TEST stow C} ; 

} 


stow I;TEST stow C); 

} 
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} 

tfote that the First three lines are the setup code which need be 
present only once regardless ot the number or specifications 
appearing in the original PL/I bo statement. These are followed 
by a pattern group which is repeated once per specification, 
separated by semicolons as necessary, and terminating with the 
final right brace. 

This general skeleton can as simplified substantially by a 
compiler if the original bO statement does not contain all of 
the most general options. For example, if tne expressions in 
either the TO or BY clauses are constants, tne corresponding 
temporaries 0 and/or V can be eliminated. If the BY expression 
is a constant, then the entice expression "signum V Is 0” can 
be evaluated at compile time, and the result can be used to 
chose the expression to ae substituted for W. Sufficient 
evaluation of constant expressions at compile time can result 
in the reduction of the general case to a much simpler program, 
like the one shown for the simple case of PL/1 DO. 


4.5.2 Translations from COBOL 


Example of EXAMINE, IF and ALT HU statements: 

EXAMINE INPUT—RECORD TALLYING ALL 
IF TALLY IS EdUAL TO u 

THEN ALIEN SNITCH TO PHOCEED TO EXIT. 

• 

SWITCH. GO TO. 

Equivalent SL statements: 

eiem sum reduction {INPUTEnCORD member V,') stow TALLY; 
eval ({; {EXIT} stow X}{ TALLY eg 0 j) ; 


goto X; 


4.5.3 Translations from FORTRA N 

Example of ARITHMETIC IF statement: 
IF (E) 12,58,13 
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Equivalent SL statement: 

yoto(signum E select (12;56; 13)) ; 

4.5.6 lranslatioas from LIS P 

Example of LISP conditional statement: 

COED ( (PI El) 

(P2 £2) 

* 

(Pn En) ) 

Equivalent SL statement; 

evai(.P1 condition El;P2 condition £2; ... ;Pa condition En) 
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a LOGICAL IMPLEM ENTATION 


A logical i mpiementa tion of the system is being defined using the 
Vienna Definition Method. initially the logical implementation 
will be presented in English. In later versions of the document, 
the formal notation will be introduced. 


4 

\ 
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EAS1C STRUCTURE 


An object con s tru ct is a storage ceil and its contents. 

A s to r age ceil is named by an nd ana contains queue (s) , a queue 
manager and an object. lid's are unique, not reused. An iid is 
the internal representation 01 a cell name. A storage cell is 
known as a b uffe r when the ownership conventions are suspended, 
e.g. a request is always sent in a butler because ownership of 
the object construct is retained by the sender until the 
recipient accepts it. 

A queue contains the lid's of buffers watch represent messages 
being sent between object constructs. yueues are organized in a 
FIFO fashion. There are request queues and response queues. 

A te guest que ue queues the lid's ox requests intended for 
processing by the access machine associated with tae object of 
this object construct. Every storage ceil has at ieast one 
request queue. 

A r espon se q ue ue queues tae ua's of responses for processing by 
the access machine associated wita the object of this object 
construct. A storage cell may aave none, one, or more response 
queues. 

A messag e whose iid is placed ou a queue is the communication 
link, to and from object constructs. There are request messages 
and response messages. 

A queue m ana g er is associated witn the queues of each storage 
cell. It is the communication interface between other object 
constructs and the object of tais object construct. As soon as 
an object construct is created, tae queue manager can begin to 
handle incoming requests. Tne queue manager of each storage cell 
can handle messages m parallel with the queue managers of all 
other storage cells in tae system. Eaca queue manager handies 
its messages sequentially. The logic of queue managing is 
written extralingualiy, e.g. in micro-code. 

An obj ec t contains an access machine and a resource. 

An ac c es s mach i ne is associated with the resource of each object. 
It is the processing interface between the queue manager and the 
resource of this object. As soon as an object construct is 
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created, the access machine can begin to process incoming 
reguests. The access machine ot eaca object can process messages 
in parallei witn the access macnrnes of ail otaer objects in the 
system. The access machine process is described by three 
components. These are a procedural description, an interpreter of 
the procedural description, ana a process status record (PSB). 
The procedural description describes the processing logic. The 
interpreter provides the actual motive force for the process by 
interpreting the procedural description. The PSB is an area of 
storage in which the interpreter records the current state of its 
interpretation of the procedural description. The logic of an 
access machine is written either extralingualiy or in SL. If the 
logic is written extralingualiy, the object is said to be 
p rimitive. If the logic is written in SL, the object is said to 
be reducible . 

A primitiv e ob ject is an object whose access machine is written 
extralingualiy. Ali requests sent to the queue manager 
associated with the storage cell containing a primitive object 
are passed by the queue manager to the access machine of the 
primitive object for processing. Xu fact, since the logic of the 
queue manager and of the access macnine are botn written 
extralingualiy, the functions or the queue manager can be merged 
into the functions of the access macxirne for primitive objects. 
Thrs is being none in the logical definition. Further, since the 
procedural description, the interpreter, and the PSB ror a 
primitive object are all extralingual entities, these components 
are not separately denoted, but are jointly denoted by the object 
type, e.g. a LIST-type object. 

A reducible ob j ect is an object whose access machine is written 
in SL. Ail requests seat to tne queue manager associated with the 
storage cell containing a reducible object are passed by this 
queue manager to the interpreter of the SL code which by being 
interpreted will process the requests. Since the procedural 
description, the interpreter, ana tne PSB for a reducible object 
are aii SL entities, these components are separately denoted by 
their three iid*s. 

A res ource contains the undifferentiated data value owned by the 
access machine. 

When communicating with foreign architectures, it is not 
meaningful to transmit the nu of a storage cell containing the 
object of interest. it is necessary to transmit the object part 
of a storage cell as a piece of data. An o bj ect image is the 
representation of the object part ot a storage ceil as data. 

Parts of the logical definition of SL require representing 
certain hardware boxes. It is advantageous to represent them as 
far as possible as object constructs. Instead of being located 
via an iid, a quasi- object construct is located via its g id . 
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Qid's are unique, not reusea, and are distinguishable from lid's. 
In ail other respects quasi-onject constructs are treated like 
object constructs. A quasi -object is a representation of an 
entity requiring service when service is provided by multiplexing 
a finite number of servers over a potentially infinite number of 
such entities. For example, the ajdLIRI-type object (quasx-SL 
interpreter) represents tae requirement for hardware multiplexing 
of a finite set of I-ooxes over all ready processes. The 
QE YAL -tyrpe object (quasi-e vaiuan t) also represents the 
requirement for hardware multiplexing of a finite set of i-boxes 
over all ready processes. Tue ^SUM-type object (quasi-sum) 
represents the requirement for hardware multiplexing of a finite 
set of adders over all ready processes. 



Ob ye cf Ccoi % f <r u, C t 



Figure 5.1-1:Structure of a Storage Cell and its Contents 
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The user who writes a strict syntax SL program deals with 
syntactic operators and syntactic simple operands. When his text 
rs interpreted, the names he usea lor his syntactic operators and 
simple operands will he resolved to some iid. informally, both 
operators and operands are represented by objects. To the user 
an operator represents an ooject which he wants to invoke, to 
pass some arguments, to have rt operate on the arguments, to send 
back an answer, and to guit. To tue user, an operand represents 
an object which the user wants to pass as an argument to some 
operator. 

The name, e.g. sum, syn, create, tor a primitively defined 
syntactic operator resolves to an rid of a storage ceii of an 
object construct whose object's object-type is PFUNCTION (for 
primitive function) ana whose resource part contains an 
indication of the primitively defined operation to be periormed, 
e.g. addition, synonym creation, ooject construction. 

The name, e.g. translate, srn, for a reducrbiy defined syntactic 
operator resolves to an rid or a storage ceii of an object 
construct whose object's type rs FUNCTION and whose resource part 
contains the iid of the SL text, the iid of SL symbol table, the 
iid of the SL link table, and the iid of the outstanding 
activation table. The interpretation of the SL text defines the 
operation to be performed, e.g. program translation, sine 
computation. 

The name for a primitively uerrned syntactic simple operand 
resolves to an iid of a storage ceii of an object construct whcse 
object's object type could be INTEGER, LIST, SYN, FUNCTION, .... 
In the case of an INTEGER-type object, the resource part is the 
integer itsell. 

The name for a redueroly defined syntactic simple operand 
resolves to an iid of a storage cell of an object construct which 
contains a reducible object. The resource part of the reducible 
object contains the iid oi storage used by SL text as it is being 
interpreted. 
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5.2.1 I ntrod uc tion 

Some of the most important basic mecuanisms are chose permitting 
message communication Between object constructs and those 
permitting message handling oy an object construct. 

The queue manager associated with the gueues or an object 
construct can invoke the message communication mechanisms. They 
are; send reguest mechanism, forward reguest mechanism, and send 
response mecnanisia. 

The gueue manager can also invoke the message handling 
mechanisms. They are: wart for reguest, read re-guest, wait for 
response, read response. 

The access machine associateu with the resource of an object 
performs the actual processing oi tne reguests ana tne responses. 

Conventions for the format oi a massage are introduced. The 
creator of tne message, tne gueue manager or the access machine, 
uses these conventions. They are; request format convention and 
response format convention. 

In describing the mechanisms m Bnglish, the logical steps are 
listed sequentially. In fact some or these steps will occur in 
parallel, and will be so noted when we describe the mecnanism in 
VDi notation. 


5.2.2 M essa ge Communic ation M echa nisms 


5.2.2.1 Send Request Mecnanism 
Queue Manager 

1. passes the following parameters to tne send request 
mechanism; the lid of the recipient of the request, the 
recipient's request queue number, the rid or the buffer 
representing the request message, the iid of tne sender of the 
request, the sender's response queue number. 
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Sena Request Mechanism 

2. produces a unique msgid. /* A msgiu is a unique identifier 
used to tag a reguest for the purpose of responding to it.*/ 

3. completes the reguest message ny adding the msgid to the 
request message. The lid of the request message is the iid of a 
buffer containing a LILT-type onject, it replaces the first 
subobject of this LIST- type object with a MSGlD-type subobject 
whose resource part contains tne msgid produced for this request 
message. 

d. adds an entry to the System communication Table. Each entry 
contains the following information: the msgid, the iid of the 
sender of the request, tne sender's response queue number, the 
iid of the recipient of tne request, the recipient's request 
queue number, and the iia of the request message. /* the first 
two pieces of information are essential to message communication. 
By keeping all these information pieces we depict the Dependency 
Graph, thus aiding resource management, system restoration, and 
system verification */. 

5. puts the iid of the request message on the specified request 
queue of the specified recipient. 

6. passes bacit to the queue manager the msgid. 



Figure 3.2.2-1:System Communication Table Entry Format 
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b. 2.2.2 Forward Request Mechanism 
Queue Manager 

1. passes the toilowing parameters to tne forward request 

mechanism: the ria of the recipient of tne request, the 

recipient's request queue number, and tne iid of the buffer 
representing the request message. 

Forward Eequest Mechanism 

2. the iid of the request message is the lid of a buffer 
containing a LIST-type object. Using the msyid in the resource 
part of the MSGID-type subonject of this LIST-type object, it 
locates the appropriate entry m tne System Communication Tabie. 

3. updates the iid of the recipient of the request and the 
recipient's request queue number with the specified new recipient 
and new request queue number. 

4. puts the nd of the request message on the specified request 
queue of the specified recipient. 

5. returns to tne queue manager 


5,2. 2.3 Send Response Mecnamsm 
Queue Manager 

1 . passes the toilowmy parameter to the send response 
mechanism: the iid of the buffer representing the response 

message. 

Send Response Mechanism 

2. the iid oi the response message in tne nd or a buffer 
containing a LIST-type object. Using the msyid in the resource 
part of the MDGID-type sunooject of this LIST-type object, it 
locates the appropriate entry m tne System Communication Table. 
The entry in the SCI speciries tne iid of the recipient of tne 
response and the recipient's response queue number. /* the 
response yoes bach with tne same msyid used to tag tne request to 
wnich it is a response*/. 

3. puts the nd of the response message on the specified 
response queue of the specified recipient. 
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4. deletes the entry from the System Communication Table 

5. returns to the queue manager 


5.2.3 M essage Hand l in g Mecna nisms 


5,2.5.1 Wait Mechanism 
Queue Manager 

1. passes the following parameters to the wait mechanism; the 
queue number to wait on or a list of queue numbers to wait on 
where the list determines the priority order or message 
retrieval. 

Wait Mechanism 

2. waits for an iid to appear on the specified queue. /* Note 
that the one wait mechanism allows waiting on a request queue or 
on a response queue/*. 

J. whan an iid appears, it passes oack to the queue manager the 
queue number on which the iid appears. 


5.2.3.2 Head Request Mechanism 
Queue Manager 

1. passes the following parameter to tne read request mechanism: 
the queue numoer containing the iid of the buffer representing 
tne request message. 

Read Request Mechanism 

2. removes the first nu from tne specified queue, 

3. deletes the iid from the specified queue. 

4. verifies that indeed the barter represents a request message. 
The iid of a request message is the iid of a buffer containing a 
LIST-type object. It checks that tne second subobject of the 
LIST-type object is a REQUESI'-type onject. 

5. it yes, it passes back to tne queue manager the iid of the 
buffer representing the request message. 


X. 
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5.2.3.3 Head Response Mechanism 
Queue Manager 

1. passes the following parameter to tne read response 

mechanism: the queue number containing the iiu of the buffer 

representing the response message. 

head Response Mechanism 

2. removes the first iia from the specirxea queue 

3. deletes the iia rrom the specified queue 

4. verifies that indeed the oufter represents a response 
message. The nd of a response message is the xid of a buffer 
containing a LIST-type object. It cnecks that the second 
subobject of the LIST-type object is not a REQUBST-type object. 

5. if yes, it passes decs. to tne gueue manager the lid of the 
buffer representing the response message. 


5.2.4 Message Process i ng 
Queue Manager 

1. passes the following parameter to the access macniue: the lid 
of tne buffer representing the request or response message. 

Access Machine 

1. /* the request processing logic provided by an access machine 

involves 'if ...then' iogic: if request so and so, then perform 
such and sucn, where sucn and such varies oy object type. For 
example, what a FUNCTION-type object does to process an execute 
request is tar different from wnat a FLOAT-type object does to 
process an execute request. The details of what actions each 
object type does as a function of receiving any possible request, 
has yet to be defined in this model*/ 
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5.2.5 M essage Format C onvent ion 


5. 2. 5.1 Request Format Convention 
Uueue Manager or Access Machine 

1. If the send request mechanism is subsequently going to be 
invoiced , the creator of the request message constructs in a 
nuffer a LIST-type object. The first subobject must be an 
ONDEF-type object. The second suoobject must oe a nE^dEST-type 
object whose resource part contains the name of tne request. The 
remaining subobjects must re uaject types appropriate to each oi 
the parameters of the request. A request need not have 
parameters but if rt does then, tor example, ii a parameter is 
the ird of some storage ceii, tae subobjact would be an ACC-type 
object. If a parameter rs some rnteger, the subobject would be 
an INTEGEH-type object. /» a buffer acquired waen some request 
was sent to the queue manager could be used as tne buffer in 
which to construct tne request */. 



Fiqure 5.2.5-1:Format of a Request 
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5.2.5.2 Hesponse format Convention 
Queue Manager or Access Machine 

1. If the send response mecaauism is suosequently going to be 
invoked, the creator cf the response message constructs in a 
buffer a LlS’i'-type object. The first subobject must be a 
MSGID-type object whose resource part contains the msgid that 
came over with the request message to which this is a response. 
The remaining subobjects must oe ooject types appropriate to each 
of taa components of the response. /* Tae buffer representing 
the request to whicn this response message is a response should 
be used as the buffer in whicn to construct the response. The 
correct msgid is already there*/. 



Figure 5,2.5-2:Format of a hespouse 
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Chapter j . 3 

KEY PROCESSING ACTIVITIES 


5.3.1 Introducti on 

The definition ot the basic mechanisms of tne gueue manager and 
the definitions of the reguest and response processing activities 
of each access machine type is essentially a logical definition 
of SL. Certain access macnine processing activities are 
especially important. Some or them are translation, expression 
evaluation and symbol resolution. The definition ot expression 
evaluation is described is described below. 

5.3.2 Express ion Eva lu ati on 

Each reducible object will cause one Q5LINT-type guasi-object to 
be spun off for the interpretation of ail the statements of the 
syntactic group associated with the reducible object. Each 
QPARALLEL-type guasi-object will cause one QSLINI-type 
quasi-object to be spun off ror the interpretation of each 
statement of the syntactic group associated with the 
QPARALLEL-type guasi-object. A QSLINT-type guasi-object is known 
as an interpreter. 

Each QS.LINT successively spins orf one QEVAL-type guasi-object 
for each statement in the statement group it is processing. A 
QEVAL-type guasi-object is known as an evaiuant. 

Each QEVAL, not handling a simple operand, spins olf a QEVAL-type 
guasi-object for each operand in the expression it is processing. 


Access Machine of the QELINT-type guasi-object (the interpreter) 

1. /* Assume that the following parameters were passed to QSL1NT 

if it ware called by a reducible object: 

(1) the iid ot an object construct which has a 
FUNCTION-type object /* this na is in tne acccess machine 
of the reducible object */. Located in the resource part of 
the FUNCTION-type object is tne iid of an object construct 
which has a LIST-type object. This niST-type object 
represents the statement group, located m the resource part 
of this LIST-type object are the lid's of object constructs 
which represent statements. A statement may either be a 
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simple operand (SYMSOLBEFEEENCE-typa object) or a complex 
operand (LIST-type object). A c omp lex op er an d is a 
LIST-type object representing an operator and its operands. 
Located in the resource part of a LIST-type object, 
representing such a complex operand, is the nd of an object 
construct which has a 3Y HBOLEEFEESMCE-ty pe object. The 
resource part of this SYfisJLHEfEhENCE-type object contains a 
symbol number. This SYhbOLEEFEEEisiCE-type object represents 
the operator. Also located in the resource part of a 
LIST-type object, representing a complex operand, are the 
iid's of object constructs representing the arguments to the 
function. These object constructs can have a 
SYMBOLEEFEHENCE-type object or a LlST-type object. 

(2) the iid of an object construct which has an UNGEF-type 
object /* this iid is in the access machine of the reducible 
object */. This UEGEF-type object represents the 
interpreter workarea (XtfA) which is part of the P3H. 

(3) the iid of the object construct representing the 
storage used by the SL program being interpreted /* tins iid 
is in the resource part of the reducible object */. 

(4) the iid of the object construct representing the actual 
arguments intended for the function. 

Assume that the following parameters were passed to ySLIET it it 
were called by a QPAEALLEL-type guasi-object: 

(1) the iid of an object construct which nas a LIST-type 
object representing a nested statement group 

(2) tne iid of an object construct which has an UNDEF-type 
object /* this iid is in tae resource part of a LIST-type 
object representing the interpreter workarea of the 
predecessor interpreter */. This UNDEF-type object 
represents a nested interpreter workarea (IWA). 

(3) the iid of the object construct representing the 
storage used by the SL program being interpreted. 

(4) the iid of the object construct representing the actual 
parameters intended ror tne function. */ 
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2. replaces the UNDEF-type object representing an IWA with a 
LIST-type object. Tais LIST-type object represents the (nested) 
interpreter workarea. 

3. augments this LIST-type object, thus creating an UNDEF-type 
object. 

4. replaces the UNDEF-type object with a LIST-type object. This 
LIST-type object represents the sequencing workarea. 

5. augments this LIST-type object twice, thus creating two 
UNDEF-type objects. 

6. replaces each UNDEF-type object with an INTEGEE-type object. 
The first INTEGER-type represents the statement counter. The 
second INTEGEH-type object represents the statement count. 

7. if it were passed the nd of an object construct which has a 
FUNCXION-type object, it retrieves the LIST-type object 
representing a statement group; else it was passed the lid of a 
LIST-type object representing a (nested) statement group. 

8. uses the request format convention and tie send request 
mechanism to send an identify request to the LIST-type object 
representing the statement group. It needs to Know the number of 
statements it is to interpret. 

9. uses the wait mechanism to wait for tae response. 

Access Machine of the LIST-type ooject representing the statement 

group 

10. uses the read request mechanism to read the identify request 

11. /* Details of how a LIST-type object processes the identify 
request are not described now*/ 

12. uses the response format convention and the sena response 
mechauism to pass bacx a response to the ■jSLINI-type quasi-object 
The response indicates the number or statements to be interpreted 
by the interpreter. 

13. uses the wait mechanism to wait for tne next request. 

Access Machine of the ySLiNT-type quasi-object (the interpreter) 

14. uses the read response mecnauism to read the response. 

15. stores tne number o£ statements in the resource part of the 
INTEGES-type object representing tne statement count. 

16. stores zero in the resource part ox the INTEGEE-type object 
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representing the statement counter. 

17. if it were passed the nd of an object construct which has a 
FUNCTIGN-type object, it binds tne parameters and handies the 
prologue if any. 

18. creates a quasi-object construct with a ^EVAL- type 
quasi-object. 

19. augments the (nested) Ima, taus creating an UNDEF type 
object. This object will represent the evaiuand. 

20. uses the request format convention and tne send request 
mechanism to send a start request to the gEVAL-type quasi-object 
just created. The parameters to start are the nd of an object 
construct which has a LIBT-type onject representing a (nested) 
statement, the iid of an object construct which has a LIST-type 
object representing the symboi tame, the nd of tne (nested) 1WA 
just created, and the iid of the object construct representing 
storage. 

21. uses the wait mechanism to wait for a response. 

Access Machine of the 2EVAi-type quasi-object (the evaluant) 

22. use the read request mechanism to read the start request. 

23. if it were passed an S¥MBGLBEFEixENCE-type object 

representing a simple operand reference, it performs steps 24-33. 
If it were passed a LIST-type object representing a complex 
operand, it performs steps Jn-oo. 

If the evaiuant were passed an S¥MBOLH£FEHENCE-type object 
representing a simple operand, then it - 

24. uses the symboi resolution mechanism to locate the iid of 

the storage cell of tne object construct represented by the 
simple operand. The symbol number in tne resource part of the 
SYMBQLHEFEHENCE-type object indicates the symbol table entry 
which corresponds to the simple operand. 

25. uses the request format convention and the send request 

mechanism to send an authorize request to the object construct 
just located. It wants a pointer to the object construct 

represented oy the simple operand. 

26. uses the wait mechanism to wait for a response. 

Access Machine of the object construct just located 

27. uses the read request mechanism to read the authorize 

request. 
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28. /* Details of how the simple operand processes an authorize 
request are uot described now */ 

29. uses the response format convention and the send response 
mechanism to pass back a response to the yEVAL-type quasi-object. 
The response indicates the nd of an object construct which has 
an METONYM-type object. 

30. uses the wait mechanism to wait tor a request. 

Access Machine or the yEVAL-typa quasi-object (the evaiuant) 

31. uses the read response mechanism to read the response. 

32. uses the send response mechanism to pass back a response to 
the interpreter (QSLINT) or evaiuant (yEVAL) that invoked it. 

33. destroys itself. 

If the evaiuant was passed a LIST-type object representing a 
complex operand, then it - 

34. replaces the UNDEF-type object representing the evaluand 
with a LIST-type object. This LIST-type object represents the 
evaluand. 

35. augments this LIST-type object twice, thus creating two 
UNDEF-type objects. 

3b. replaces the second UNDEF-type object with a LEQUEST-type 
object whose resource part contains the name evaluate. 

37. uses the symbol resolution mechanism to locate the iid of the 
storage cell of the object construct represented by the operator. 
The syatbol number in the resource part of the 
SY MBQLSB PEhENCE-type object indicates the symbol table entry 
whica corresponds to the operator. 

38. uses the request format convention and the sena request 
mechanism to send an identify request to the object construct 
just located. it must know if the object construct just located 
represents a function and ir so, it the number of operands 
syntactically supplied is equal to the number of actual 
parameters semantically required by the function. 

39. uses the wait mechanism to wait for a response. 

Access Machine of the object construct just located 

40. uses the read request mechanism to read the identify 

request. 
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41. /*Detaiis of how the object processes the identify request 
ace not described now */ 

42. uses the response format convention and the send response 
mechanism to pass back a response to the QEAUL-type quasi-object. 
The response indicates whether or not an evaluate request will be 
processed and the number of semantically required parameters. 

43. uses the wait mechanism to wait for a request. 

Access Machine of the QEVAL-type quasi-object (the evaiuaut) 

44. uses the read response mechanism to read the response. 

45. uses the request tormat convention and send request 
mechanism to send an identify request to the LISI-type object, 
representing the complex operand, sent to it as a parameter. It 
wants to know the numoer of actual parameters syntactically 
supplied. 

46. uses the wait mechanism to wait for a response. 

Access Machine of the LIST-type onject 

47. uses the read request mechanism to read the identify 
request. 

4d. /* Details ol how the object processes the identify request 

are not described now*/ 

49. uses the response rormat convention and the sena response 
mechanism to pass back a response to the v 2 EVAL-type quasi-object. 
The response indicates the number of subobjects augmented from 
this LIST-type object. 

50. uses the wart mechanrsm to wart for a request. 

Access Machine of the QEVnl-type quasi-object (the evaiuant) 

51. uses the read response mechanism to read the response. 

52. subtracts one from tae number sent bacx. rn this response ana 
verifies that the number or syntactically supplied parameters 
equals the number of semantically required parameters. 

53. tor each parameter it creates a quasi-object construct with 
a QEVAL-type quasi-object; it augments tne (nested) IWA, thus 
creating an UttDEF-type object representing an evaluand; and it 
uses the request format convention and the send request mechanism 
to send a start request to the jEVAL-type quasr-object just 
created. The parameters to start maicate the expression to be 
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interpreted, the symbol table, the (nested) IWA just created, and 
the storaqe. For eacn parameter it augments the LIST-type 
object, representing its evaiuand, thus creating UNDEF-type 
objects; and it replaces these UNDEF-type onjects with fiSGlD-type 
objects whose resource part contains the rnsgids of the various 
start requests. /* The order of the MSGXD-type objects in the 
evaiuand reflect the order m wuich parameters will be passed to 
the function*/ 

54. uses the wait mechanism to wait for a response. 

Access Machine of QEVAL-type quasi-object 

55. uses the read response mechanism to read the response. 

56. uses the msyid of the response to locate the appropriate 
MSGID-type object in its evaiuand. 

57. replaces the MSGID-type object with the object whose lid was 
passed bach m the response. 

58. deletes from the LIST-type ooject representing its INA, the 
LIST-type object representing the evaiuand of the evaluant which 
just returned the response. 

59. determines if its evaiuand contains any outstanding 
messages. If it does, it uses the wait mechanism to wait for a 
response, and repeats steps 55-59 as necessary 

/* If individual operand evaluation should be done in sequence 
rather than in parallel, the evaluant performs ail the steps 
53-59 for each operand */ 

60. uses the send request mechanism to send the evaluate request 
to the object construct represented oy the operator located via 
the symnol resolution mechanism m step 37. /* i'ne request format 
convention was adhered to m the construction of this request, 
since the evaluant built up tne request m the evaiuand.*/ 

61. uses the wait mechanism to wait for a response, 

62. /* Details of now a function processes its parameters are 
not describe! here -- see scenarios 1 and 2 */ 

63. uses the read response mechanism to read the response. 

64. uses the send response mechanism to pass back the response 
to the interpreter (dSLINT) or evaluant (yEVAL) tnat invoked it. 

65. destroys itself 

Access Machine of a ySLINT-type quasi-ohject 
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t>6. uses the read response mechanism to read the response. 

67. deletes from the LIST-type object representing his IWA, the 
LIST-type object representing the evaruand of the evaluant that 
just returned the response. 

66. determines if there are more statements in the group to be 
processed by comparing tne statement count with the statement 
counter. If there are, it adds one to the statement counter, and 
goes back to step 18. 

69. uses the send response mechanism to pass bacs a response 
either to the reducible onject or the ALLEL-type guasi-object 
that called it. 

70. destroys his IWA 
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5.4.1 Introduction 

The scenarios are examples chosen to tie together iaeas presented 
under Basic Structure, Basic Mechanisms, and Key Processing 
Activities. 

5.4.2 U sing a Pr imitive Byn tact ic 0pe rato r 
(.. .; sum (a,b) ; . .. } 

Expression Evaluation 

1. /* Assume that the expression evaluation mechanism has 
reached the point where it is ready to invoke the sum tuncticn, 
passing it the evaluated simple operands a and 5 as actual 
parameters */ 

2. uses the send reguest mechanism to send tae evaluate reguest 

to the object construct name a sum wmch was located via the 

symbol resolution mechanism. The parameters to evaluate are the 
iid*s of the object constructs named a and b. 

i. uses the wait mechanrsm to wait cor a response. 

Access Machine of the PFUhCTiON-type object (the sum function) 

4. uses the read reguest mechanism to read the evaluate reguest. 

5. creates a guasr-ouject construct with a gSUM-type 
quasr-object. 

6. uses the reguest format convention and the rorward reguest 

mechanism, /* uo new msgiu */, to forward a start request to the 
QSUM-type guasi-ob ject just created. The parameters to start are 
the iid's of the object constructs named a and a . 

7. uses the wart mechanism to wart for the next request. /* The 

PFUNCTiON-type object is completely severed from tae QSUM type 
guasi-ob ject*/ 

Access Machine of the QSUM type guasi-ongect 

8. uses the read request mecnanrsm to read the start request. 
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9. /* Details o£ precisely Low ySUM does the addition of a and b 
are not described now */ 

10. uses the response format convention and the send response 
mechanism to pass bacK a response to the expression evaluation. 
The response consists of the ird of the object construct which 
represents the result of adding a and b. 

11. destroys itself 
Expression Evaluation 

12. uses the read response aecaamsm to read tae response. 

13. /* Refer to the expression evaluation mechanism for details 
of response handling */ 



Figure 5.4,2-1:Primitive Operator flow 
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5.4.3 Usin g a Red u ci ble Syn tac ti c Op erator 


{.. . ;sin (x) ; . .. j 

Expression Evaluation 

1. /* Assume that the expression evaluation mechanism has 

reached the point where it is ready to invoke the runction sin, 
passing it the evaluated simple operand x as an actual parameter 
V 


2. uses the send reguest mechanism to send the evaluate reguest 
to the object construct named sin which was located via the 
symbol resolution mechanism, Tne parameter to evaluate is the iid 
oi the object construct named x. 

3, uses the wait mechanism to wait tor a response. 


Access Machine or the PUNCTION-type object (the sm function) 

4. uses the read reguest mechanism to read the evaluate reguest. 

5. creates an object construct with an UNDEf-type object. 

6. replaces the UNDEF-type object with an object whose access 
machine contains three lid's: the iid of the object construct 
named sin which has a FUNCIION-type object /* tne SL interpreter 
will need access to the EL text and symbol table */; the iid of 
the object construct named simt which has a PFUNOTION~type 
object /* this PFUNCTION-type object will spin off an SL 
interpreter */; and tne iid oi an object construct which has an 
CJNDEF-type object /* this is the P58 and will be used by the SL 
interpreter for its worxspace */. Such an object is a reducible 
object, 

7. uses the reguest r or mu t convention and the senu request 
mechanism to send a start request to the reducible object just 
created. Tne parameter to start is the iid ot the object 
construct named x. 

3. adds an entry to its Outstanding Activation Table, The entry 
contains the rnsgid ot the evaluate request just processed, the 
msgid of the start request just sent to the reducible object, and 
the lid of the reducible object. /* Each FUNCTION-type object 
must keep a record oi ail spun-off reducible objects still active 
so that it can block change requests (a request to change the SL 
text) until ail spun-off reducible objects nave terminated or 
suspended */. 

9. uses the wait mechanism to wait for the next request or 
response. /* The FUNCTION-type object is effectively severed from 
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the reducible object since the FUNCTION-type object may now 
process new requests or replies. */ 

Queue Manager oi the Heducinle Object 

10. uses the read reguest mecnanism to read the start reguest. 

11. uses the reguest format convention and the send request 

mechanism to send an evaiuate request to the object construct 
named slant which was located via the lid m tne access machine 
of the reducible object. The parameters to evaiuate are the iid 
of the object construct named sin which has a FUNCTiON-type 
object/* this iid is in the access machine of the reducible 
object*/; the iid of an ooject construct which has an UNDEF-type 
object /* this iid is in the access machine of the reducible 
object */; the iid of the ooject construct usea for storage by 
the interpreted SL program /* this iid is in the resource part of 
the reducible object */; and tne iid of the request sent to it by 
the FUNCTION-type object (the sm function) /* this request 
contains a start request type and the iid of the object construct 
named x */. /* The queue manager associated with a reducible 

object always packages up the requests sent to it and sends them 
on without examination for their interpretation by SL text */ 

12. uses the wait mechanism to wait for a response. 

Access Machine of the PFUNCTION-type object (the SLINT function) 

13. uses the read request mechanism to read the evaluate 
request. 

14. creates a quasi-object construct with a QSLINT-type 

quasi-object. 

15. uses the request format convention and the forward request 
mechanism to send a start request to the QSLINT-type quasi-object 
just created. The parameters to start, are identical to the 
parameters or the evaluate request discussed m step 11. 

16. uses the wait mechanism to wait for the next request. /* The 
PFUNCTION-type object is completely severed from the QSLINT type 
quasi-object */. 

Access Machine oi tne QSLiNT-type quasi-object 

17. uses the read request mecnauism to read the start request. 

18. since the object representing the process status record 
(PSR) is an UNDEF-type object (i.e. it is initialized), the 
QSLiNT-type quasi-ooject Enows that it is not resuming a 
suspended interpretation, but is oeginnmg a new interpretation. 
Therefore, it binds the parameters intended ior processing by SL 
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code, and it augments the storage named in the resource part of 
the reducible object. It brads tne parameter, the ira of the 
object construct named x, as follows: it locates the symbol 
number of the formal parameter ru the SL symbol table. The 
property of being a formal parameter has oeea associated with the 
symbol number. It then locates the 5L link table entry using the 
symbol number as offset, ana inserts the rrd of the object 
construct named x into the lid slot of the entry. 

19. /* Detaris of interpretrng SL text representing the sin 
operation are not described now. 'deter to the expression 
evaluation mechanism for details on interpreting SL text */. 

20. uses the response format convention and the send response 
mechanism to pass back a response to the reducible object. . The 
response consists of the iid of tne object construct computed by 
the interpretation of the SL text representing the sin function. 

21. destroys itself 

Queue Manager of the reducible object 

22. uses the read response mechanism to read the response. 

23. uses the send response mechanism to pass back the response 
to the FUNCTION-type object (the sin function). The response 
consists of the iid of the object construct computed by the 
interpretation of the SL text representing the sm function. 

24. since the PSfi indicates that an SL return function had been 
interpreted, it destroys itself. 

Access Machine of the FUNCTION-type object (the sm function) 

25. uses the read response mechanism to read the response. 

26. uses the msgid in the first subohject of the LIST-type 
object representing the response to search the Outstanding 
Activation Table for the appropriate entry, retrieves the msgid 
of the original evaluate reguest for use m step 27 and deletes 
the entry. 

27. uses the send response mechanism to pass back the response 
to expression evaluation. The response consists of the iid of 
the object construct computed by the interpretation of the SL 
text represented by the sin operator. 

28. uses the wait mechanism to wait for the uext reguest or 
response. 

Expression Evaluation 
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The following words and phrases include terms formally defined m 
the logical architecture together with important terms in the 
informal discussions, words beginning with lower case letters 
are built-in objects, either constants or functions. Numbers in 
parentheses indicate the section in which the term is defined. 
The letters (GT) indicate terms from graph theory. 


Access machine (2.1.3) The active part of an object that responds 
to requests upon the object. 

Accessibility graph (2.1.5) a graph of all paths for accessing 
objects. It has two major subgraphs: tae ownership tree 
and the chains of synonyms. 

Accessible (2.1.5) An object x is accessible from y if there is a 
path in the accessibility graph from y to x. 

Activation tree (2.2.5) A tree fluxing activations of functions 
to the activations of functions tney called. It is a 
subgraph of the dependency graph. 

Admissible index set (2.1,5) A Set of objects admissible as 
indices to the access machine of a collective object. 

Argument (2.2.5) The result or evaluating an operand for a 
function. 

Assignment (2.1.4) An informal term for referring to the stow and 
replace functions. 

authorize (2,1.5) A dyadic function that males an authorize 
request upon an object in order to obtain a synonym to the 
object with a given set of ngnts. 

buffer (2.1.1) A temporary storaje cell used for holding an 
object or shipping it somewhere else. 

Cell name (2.1.1) An identifier that uniquely specifies a storage 
cell. 

Chain (GT) A graph whose edges uerihe a strict linear ordering of 
the vertices. it is both a tree and a rooted tree. 
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Circuit (GT) A path whose first and last vertices ace identical. 

Collective object (2.1.5) An ooject that owns storage cells 
containing other objects. 

Connected graph (GT) A graph rn which for any two vertices x and 
y, there exists an undirected path from x to y. 

create (2.1.4) A dyadic function that creates a new object by 
activating an access machine and providing it with initial 
values for its owned resource. 

Deadlock (2.5.1) A state of tae system in which a set of queued 
requests can never be resolved. It results from a circuit 
in the dependency graph. 

delete (2.1.6) A dyadic function that deletes storage cells from 
the owned resource of a collective object. 

Dependency graph (2.1.3) A graph of outstanding requests upon 
objects: if x is waiting for a request on y, then (x,y) is 

an edge of the dependency graph. 

Descriptor (2.1.3) An implementation defined representation of an 
access machine: it contains a PSR and specifies the 

interpreter and procedural description. 

Dictionary (2.2.2) For each module, the dictionary maintains 
information about aii symbols: character representation, 
linkage, and initial attributes. 

Directly accessible (2.1.5) An object x is directly accessible 
from y if there is a path in the ownership tree from y to x. 

Edge (GT) An ordered pair of vertices in a graph. 

Element (2.1.5) An object residing in a storage ceil owned by a 
collective object. 

Elementary symbol (2.2.3) A symbol in program text without any 
syntactically associated operands. 

Elementary object (2.1.5) An oaject that does not own any storage 
cells; ail elementary objects are scalars. 

Environment tree (2.3.3) A rooted tree tnat defines search paths 
for symbol resolution. 

evaluate (2.1.4) A monadic function that makes an evaluate 
request on its argument to deliver or generate a value. 


IDE CONFIDENTIAL 



Appendix 1 


GLGbbAny 


231 


Exception (2.4.1) A response ny an access machine indicating that 
the normal response cannot be mane. 

Extended syntax (1.3. 3) An mrix notation that includes macro 
facilities to be mapped into scrict syntax. 

Forest (GT) A graph consisting or one or more unconnected trees. 

Function (2.1.4) An object that responds to evaluate reguests by 
creating an activation that computes an object as result. 


Generator (2.1.7) A collective oogect whose elements are computed 
upon demand instead of being stored in the SiiS. 

Graph (GT) A set oi points c a ilea vertices and or ordered pairs 
of vertices called edges. Only directed graphs are used in 
the discussion. 

Group (2.2.3) A list of statements enclosed in braces. A group 
is the external form of a laoauie. 

rdentiry (2.1.4) A monadic runction that asxs an object to 
identify its access machine. 


liist (2.1.5) A monadic runction that returns the index set of a 
collective object. 

incoming edge (GT) An edge (x, y) is an incoming edge with respect 
to the vertex y. 

Index set (2.1.5) The set of objects mapped by select reguests 
onto storage cells of a collective object. 

indirectly accessible (2.1.o) An object x is indirectly 

accessible from y if tuere is a cnain of synonyms from y to 

x. 


insert (2.1.6) A dyadic runction that inserts new storage cells 
m the owned resource oi a coirectrve object. 


Interpreter (2.1.2) The motive torce behind a process; it 
examines the PSR, decodes the procedural description, and 
puts the PSB in its next state. 


lambda (2.2.3) A function chat creates a 
formal parameters to a module. 

List (2.1.5) The most primitive type of 
elements are luaexeu by consecutive 
and may be of different types. 

detonym (2.1.5) An encapsulated synonym. 


new function by binding 

collective object. Its 
integers starting at 0 

It is used tor pointers 


LtiA COM ibEilTIAL 



232 


APP BN Died S 


Appendix 1 


in PL/i to conform to restrictions in the language 
definition. 

Module (2.2.2) The machine rorm oi a group; it contains the text 
for the group together w nth a dictionary or ail symbols in 
the group. 

nil (2.1.3) A primitive object that has the properties of a zero 
element list. 

Object (2.1.3) Basic entity in the system; it has an active part 
called an access machine and a passive part called an owned 
resource. 

Object base (2.1.3) Set oi ail objects in the system. 

Object image (2.1.3) An internal representation oi an object: it 
contains the descriptor of its access machrne and a 
representation of the owned resource. 

Offset (2.1.1) A displacement rrom the beginning of a table. 
This term rs not a formal part oi the definition. 

Operand (2.2.3) An expression in program text that evaluates to 
aa argument for a function. 

Operator symbol (2.2.3) A symbol that resolves to a function and 
that has syntactically associated operands. 

Outgoing edge (OT) Aa edge (x,y) rs an outgoing edge with respect 
to the vertex x. 

Owned resource (2.1.3) Passive part of an object that rs managed 
by the access machine. 

Ownership tree (2.1.3) A tree ueirned over the object base by the 
ownership relation between collective objects and storage 
cells. 

parallel (2.2.5) A monadic function that causes the statements of 
a module to be executed in parallel. 

Parameter (2.2.3) A symbol local to a module that is resolved to 
an argument every time tne module rs activated. 

Path (G'T) A seguence of vertices of a graph G such that if x and 
y are adjacent vertices, (x,y) is an edge of G. 

Port (2.1.3) An object whose access machine and resource connect 
to a data path through the Source-SinK Subsystem (see the 
System Architecture Manual) . 
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Primitive object (2.1.3) Au object that cannot be constructed 
from other objects defined in the logical architecture. 

Procedural description (2.1.2) Encoded information tnat defines 
the states of a process ana permissible state transitions. 

Process (2.1.2) An automaton tnat has three parts: a process 

status recoru (PSu) , a procedural description, and an 
interpreter. 

Process status recoru (2. 1.2) The record of the current state of 
a process, its input, and its working storage. 

Program text (2.2.3) A string of symbols. 

PSR (2.1.2) Abbreviation for process status record, 

guote (2.2.3) A syntactic marxer that suppresses automatic 
evaluation of a function. 


heady state (2.1.3) State of au access machine when it is ready 
to respond to a re guest. 

Reducible object ' (2. 1. 3) An object that can be constructed from 
more primrtive objects in the logical architecture. 

remove (2.1.6) A monadic function that removes an object from a 
storage ceil without deleting the cell. 

replace (2.1.6) A dyadic function used for assignments that 
replace the target completely. 

Reguast (2.1.3) A parr of parameters passed to an object to 
reguest some service. 


Reserved word (1.3.4) A string of two or more lower case letters 
used to designate system defined objects and various 

constructions in the extendeu syntax. 


Resource manager (2.5.3) The object in a subsystem that obtains 
rights to objects outside or cue subsystem and allocates the 
rights to other objects within it. 

Rights (2.1.5) A set of requests that a synonym passes on to the 
object it points tc. 


Root (GT) The distinguished vertex of either a tree or a rooted 
tree. 


Rooted tree (GT) A connected graph in which there is a 
distinguished vertex wita no outgoing edges and all other 
vertices have exactly one outgoing edge. 
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Seed (GX) A tree with one vertex and no edges. 

select (2.1.5) A dyadic inaction that makes select requests on a 
collective object to map indices onto storage ceils. 

Sequential synonym (2.1.b) a synonym that can be sequenced 
through successive elements oi a collective object. 

SMS (2.1.1) Abbreviation for the Storage Management Subsystem 
(see the System Architecture Manual). 

Space number (z.1.1) A number identifying a logical space in the 
SMS. This term refers to tne implementation rather than to 
the formal definition. 

Statement (2.2.3) A complete expression used as one element of a 
module. 

Storage cell (2.1.1) A logical location large enough to contain 
any object. 

stow (2. 1.4) A dyadic function that maxes a stow request on the 
target to perform assignments. It makes a less drastic 
change than the replace function. 

Strict syntax (1.3.2) A prefix notation tnat is mapped one-to-one 
into the internal machine code. 

Strongly connected grapn (GT) A graph in which for any two 
vertices x and y, there exists a path from x to y. 

Structure (2.1.7) A subtree of the ownership tree together with 
all objects accessible from objects m the tree. 

Subsystem (2.5.3) A subset of the object base having only one 
point of connection with the graphs linking the rest of the 
system. 

Symbol (2.2.3) A string of one or more characters. 

Symbol resolution (2.2.1) The act oi resolving symbols to cell 
names of storage cells containing objects. 

syn (2.1.5) A monadic function that makes an authorize request to 
obtain a synonym that responds to copy and destroy requests 
itself. 

Synonym (2.1.5) An object that automatically passes requests to 
the object whose storage cell it names. 

System root (2.1.5) The object at the root of the ownership tree; 
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all objects in the system die directly accessible ttorn the 
system root. 

Tree (GT) A connected graph in which there is a distinguished 
vertex with no xacoaiay edges, and ail other vertices have 
exactly one incoming edge. 

under (2.1.3) A primitive undermed object. 


Undirected path (GT) A sequence or vertices or a graph G such 
that if x and y are adjacent vertices, then either (x,y) or 
(y,x) is an edge of G. 

Vertex (GT) A point on a grapa. 
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Enclosed is an index to the "Fundamental Concepts and System 
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access machine 31,201,229 

accessibility graph 44,229 

accessible 44,229 

acquire function 107 

activate phase 57 

activating a function 58 


37,68 

72 

73.229 
229 
105 
147 

73,106,164 

229 

70 

5 3 

97 

40.165.229 
36 


base list 

53 

base value function 

105 

basis 

54 

braces 

65,73,94,166 

buffer 

27,201 ,229 

catenate function 

97 

ceiling function 

104 

cell name 

27,229 

claim function 

107 

collective object 

41 ,230 

complete index set 

54 

compress function 

105 

conditional function 

74,106,167 

connect function 

76,95 

consumable 

85,147 

contained 

66 

control program 

116 

controlling process 

81 

copy function 

0 

copy request 

36 

create function 

77,80,95,106,168,230 

cursor 

73 

data base 

134 

data communication 

145 
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activation chain 
activation tree 
admissable index set 
and function 
answer 

apply function 
argument 
argument list 
array 

augment function 
authorize function 
authorize request 
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deactivate phase 

deadlock 

declare 

dedicated ports 
dedicated subsystem 
defined 

delay function 
delayed parse function 
delete Function 
delete reqtiest 
delimiter 
deoend 

dependency graph 
depth 

destroy function 
destroy request 
dictionary 
difference function 
directly accessible 
directly contained 
disclose function 
dron function 


57 

85,229 

169 

115 

116 
61 

73.106 
65,94 

48.97.170.230 
36 

171 

35 

35.230 
52 

80.106 

36 

60.230 
104 

43.230 
66 

98,172 

106 


element 

elementary object 
elementary symbol 
enclose function 
environment 
environment tree 
environmental chain 
eq function 
evaluand 

evaluate function 
evaluate request 
evaluation 
exception 
execute phase 
exit function 
exp function 
expand function 
expression 
extended syntax 


41,230 

41.230 

63.230 
98,173 

75 

76.230 

76 
105 
59,71 

38.106.174.230 
36,68 

69,70,71,202 

79.231 
57 

74,106,175 

104 

105 
66 

23.231 


finite resource 
floor function 
free function 
free ports 
free subsystem 
free symbol 
function 

functional level 


87 

104 

107 

115 

116 
61 
37 
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ge function 

105 

generator 

99,231 

goto function 

74,105,175 

group 

65,231 

group markers 

65 

gt function 

105 

i-dimension index 

53 

ibase function 

96,177 

identify function 

231 

identify request 

36 

igenerator function 

96,99,178 

ignore function 

81 ,106 

iid 

27 

ilist function 

43,96,179,231 

index function 

101 

index object array 

55 

index set 

42,231 

indexed structure 

52 

indirectly accessible 

43,231 

initial interpreter 

116 

inject function 

81 ,1 06 

inner nroduct function 

too 

insert function 

47,97,180,231 

insert request 

36 

insert symbol function 

60,95 

inter-AFS job 

147 

intercept 

81 

interpretation 

58,70 

interpreter 

28,231 

introduce function 

107,148 

j ob 

118 

k-list 

54 

k-vector 

54 

label 

181 

lambda function 

67,95,182,231 

le function 

105 

linking 

76 

list 

42,231 

list function 

97 

list structure 

52 

literal symbol 

63 

In function 

104 

load function 

95 

load phase 

57 

local environment 

75 

local label prototype 

62 

local symbol 

61 

locate function 

101 
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log function 104 

It function 105 

104 
1 00 
54 

104 

105 

147,201 

41.231 

156 
104 
103 

60.232 
81,106 


name_value function 97 

nand function 105 

ne function 105 

nil 32,232 

nor function 105 

not function 105 


magnitude function 
map function 
matrix 

max function 
member function 
message 
metonym 
migration 
min function 
minus function 
module 

monitor function 


obj ect 

object base 

object construct 

obj ect image 

offset 

operand 

operating system 
operator symbol 
or function 

outer product function 
own 

owned resource 
ownership tree 


31 ,201 ,232 

34.232 
201 

33.202.232 
232 

64.232 
116 

63.232 
105 
100 

41 

31.202.232 

42.232 


parallel function 
parameter symbol 
parentheses 
path 

path name 
phases 

plus function 
point function 
port 

power function 
predecessor environment 
primitive argument 
primitive array 
primitive index set 
primitive object 


72.106.183.232 

61.67.232 
184 


47.232 
47 

57 

103 
99 

33.232 

104 
76 
93 
54 
51 

31,202,233 
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priority function 

81,106 

procedural description 

28,233 

process 

28,233 

process status record(PER) 

28,233 

product fucntion 

104 

program text 

62,233 

pseudo list 

53 

qeval 

203 

qslint 

203 

qsum 203 


quasi-activation 

38 

quasi-obj ect 

203 

queue 

201 

queue manager 

201,205 

aid 

202 

quote 

64,94,233 

quotient remainder function 

104 

quotient function 

104 


r-array 

rank 

ravel function 
ready states 
rebase function 
reciprocal function 
reducible object 
reduction function 
release function 
remove function 
reoeat function 
replace function 
representation 
representation function 
representative symbol 
request 

request constant 
request function 
request queue 
reshape function 
residue function 
resolution mao 
resource manager 
resource packages 
response queue 
reverse fucntion 
rights 

rotate function 


53 

53 

98 

31.233 

98 

103 

32.202.233 

99 
107 

48.99.185.233 
74,106,186 

48.77.99.187.233 
33 

105 
63 

35.233 

37 

38 

201 ! 

98 

104 
75 

88.114.233 
115 

201 

106 

39.233 
106 


safe sequence 
select function 
select request 


89 

43,96,106,188,234 

36 
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semicolon 

189 


send answer function 

107,148, 

207 

send message function 

107,148, 

205 

sequence exception 

80 


sequential synonym 

234 


server configuration 

121,127 


shape function 

52,53,96 

,190 

signal function 

79,106 


signum function 

103 


simple exDression 

64 


simple name 

47 


SMS 

2 34 


space number 

234 


source/sink 

147 


start function 

80,106 


start request 

37 


statement 

66,234 


statement index 

59 


sten function 

97 


stop 

76,95 


storage cell 

27,201,234 

stow function 

39,77,99 

,191,234 

stow request 

37 


strict syntax 

22,234 


structure 

52,234 


subsystem 

88,234 


subsystem landlord 

115 


subsystem resource managers 

116 


subsystem root 

88 


sum function 

104 


suspend function 

80,106 


symbol 

63,234 


symbol reference 

60 


symbol resolution 

59,234 


syn function 

40,99,192,234 

synonym 

39,234 


system input 

116 


system root 

42,234 



take function 
text 

ton onerator 
translate function 
translate machine 
translate nhase 
translate subject 
transnose function 


106 

62 

64 

108,110 

108 

57 

108 

0 


ultimate function 99 

unbounded resource 87 

undef 32,235 

unique name function 95 
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unique resource 87 

unload phase 57 

vector 54 

visible 75 


wait answer function 
wait message function 
where 
work flow 


107,148,708 

107,148,708 

77 

125 
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